I added two breakpoints in functions of one shared library (.so) and ran gdb 7.4 and attached it to a process.
Gdb hit the breakpoint and I ran n for several steps, and gdb reported the following errors(with bold text):
(gdb) b [function name]
Breakpoint 1 at 0xf1f28a49: file ../../../../../[file name].cpp, line 167.
Breakpoint 2 at 0xf1f2dae5: file ../../../../../[file name].cpp, line 60.
warning: Multiple breakpoints were set.
Use the "delete" command to delete unwanted breakpoints.
(gdb) c
Continuing.
[New Thread 0xcaafab90 (LWP 28480)]
[Thread 0xcaafab90 (LWP 28480) exited]
[New Thread 0xcaafab90 (LWP 29558)]
[New Thread 0xc8cb6b90 (LWP 29980)]
[Switching to Thread 0xc8cb6b90 (LWP 29980)]
Breakpoint 2, [function name] (ostr=..., clientResponse=..., httpProtocol=..., >reqType=...) at ../../../../../[file name].cpp:60
60 ../../../../../[file name].cpp: No such file or directory.
in ../../../../../[file name].cpp
(gdb) ni
0xf1f2daed 60 in ../../../../../[file name].cpp
(gdb) n
Breakpoint 1, [function name] (ostr=..., clientResponse=..., httpProtocol=..., >closeConn=..., asynchResponse=..., reqType=...)
at ../../../../../[file name].cpp:167
167 in ../../../../../[file name].cpp
(gdb) n
Warning:
Cannot insert breakpoint 0.
Error accessing memory address 0x36cc6dde: Input/output error.
0xf7082771 in siglongjmp () from /lib/libc.so.6
(gdb)
This is the output from /proc/[PID]/maps:
08048000-08146000 r-xp 00000000 08:03 293876
08146000-08150000 rw-p 000fe000 08:03 293876
08150000-099c8000 rw-p 08150000 00:00 0
[heap] c21f9000-c21fa000 ---p c21f9000 00:00 0
c21fa000-c29fa000 rwxp c21fa000 00:00 0 c29fa000-c29fb000 ---p
c29fa000 00:00 0 …… f1e1b000-f1e24000 rw-p f1e1b000 00:00
0 f1e24000-f2093000 r-xp 00000000 08:03 295549
.so f2093000-f2094000 ---p 0026f000 08:03 295549
.so f2094000-f2098000 r--p 0026f000 08:03 295549
.so f2098000-f209c000 rw-p 00273000 08:03 295549
.so f209c000-f209d000 rw-p f209c000 00:00 0
My questions are:
Gdb fails to insert internal breakpoint for ni command, but why does it try to access address 0x36cc6dde if the text section is at 0xf1******?That address is not included in the output of maps as you can see.
More general question, I was told shared library starts at 0x40000000 but why this is not the case in my environment?
The shared library is compiled with -fPIC. I hide some symbol names in the traces above.
This is probably related to http://sourceware.org/bugzilla/show_bug.cgi?id=13987. Please, could you try the latest FSF GDB HEAD (can be obtained from: git://sourceware.org/git/gdb.git).
Related
I have a project that reads data from ethernet port and runs a set of algorithms on it.The program runs fine for a couple of hours and then produces the below shown error.
Could some suggest how to debug, find the line thats causing error ??
*** Error in `objs/x64Linux3gcc5.4.0/lidarToBoxes': malloc(): memory corruption: 0x00000000051fc640 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7f230dc167e5]
/lib/x86_64-linux-gnu/libc.so.6(+0x8213e)[0x7f230dc2113e]
/lib/x86_64-linux-gnu/libc.so.6(__libc_malloc+0x54)[0x7f230dc23184]
/usr/lib/nvidia-384/tls/libnvidia-tls.so.384.111(+0x24c0)[0x7f2304e6e4c0]
======= Memory map: ========
00400000-00dc6000 r-xp 00000000 08:03 38407960 /home/sai/sai_workspace/avt_17_003/modules/lidarToBoxes/objs/x64Linux3gcc5.4.0/lidarToBoxes
00fc5000-00fcf000 r--p 009c5000 08:03 38407960 /home/sai/sai_workspace/avt_17_003/modules/lidarToBoxes/objs/x64Linux3gcc5.4.0/lidarToBoxes
00fcf000-00fd5000 rw-p 009cf000 08:03 38407960 /home/sai/sai_workspace/avt_17_003/modules/lidarToBoxes/objs/x64Linux3gcc5.4.0/lidarToBoxes
00fd5000-00ff0000 rw-p 00000000 00:00 0
0220b000-0614a000 rw-p 00000000 00:00 0
[heap]
7f22d0000000-7f22d0022000 rw-p 00000000 00:00 0
7f22d0022000-7f22d4000000 ---p 00000000 00:00 0
7f22d4000000-7f22d4021000 rw-p 00000000 00:00 0
7f22d4021000-7f22d8000000 ---p 00000000 00:00 0
7f22d8000000-7f22d8021000 rw-p 00000000 00:00 0
7f22d8021000-7f22dc000000 ---p 00000000 00:00 0
7f22dc000000-7f22dc07c000 rw-p 00000000 00:00 0
7f22dc07c000-7f22e0000000 ---p 00000000 00:00 0
7f22e0000000-7f22e0021000 rw-p 00000000 00:00 0
7f22e0021000-7f22e4000000 ---p 00000000 00:00 0
7f22e6ffe000-7f22e6fff000 ---p 00000000 00:00 0
7f22e6fff000-7f22e77ff000 rwxp 00000000 00:00 0
7f22e8000000-7f22e8021000 rw-p 00000000 00:00 0
7f22e8021000-7f22ec000000 ---p 00000000 00:00 0
7f22eeffe000-7f22eefff000 ---p 00000000 00:00 0
7f22eefff000-7f22ef7ff000 rwxp 00000000 00:00 0
7f22ef7ff000-7f22ef800000 ---p 00000000 00:00 0
7f22ef800000-7f22f0000000 rwxp 00000000 00:00 0
7f22f0000000-7f22f00a6000 rw-p 00000000 00:00 0
7f22f00a6000-7f22f4000000 ---p 00000000 00:00 0
7f22f4000000-7f22f4021000 rw-p 00000000 00:00 0
7f22f4021000-7f22f8000000 ---p 00000000 00:00 0
7f22f8000000-7f22f8021000 rw-p 00000000 00:00 0
7f22f8021000-7f22fc000000 ---p 00000000 00:00 0
7f22fc093000-7f22fc291000 rw-p 00000000 00:00 0
7f22fc291000-7f22fc491000 rw-s 00000000 00:09 323133
socket:[323133]
Thank you!
Based on this first message, the list of unsorted chunks for one particular arena has become corrupted:
* Error in `objs/x64Linux3gcc5.4.0/lidarToBoxes': malloc(): memory corruption: 0x00000000051fc640 *
You can see that by the fact that it says "malloc(): memory corruption" and not, for example "malloc(): memory corruption (fast)". The values at the end of the message vary between releases of glibc but in your particular case what you are seeing is the value of "victim" from code something like this:
while ( (victim = unsorted_chunks(av)->bk) != unsorted_chunks(av)) {
bck = victim->bk;
if (__builtin_expect (victim->size <= 2 * SIZE_SZ, 0)
|| __builtin_expect (victim->size > av->system_mem, 0))
malloc_printerr (check_action, "malloc(): memory corruption",
chunk2mem (victim));
size = chunksize(victim);
In my particular case I grabbed this from glibc-2.18/malloc/malloc.c because, based on the fact that you had one number after the message, your version of glibc seemed near 5.18 but that was just a guess. Your backtrace specifies "/lib/x86_64-linux-gnu/libc.so.6" as the library, which is a bit vague, but if you wanted to find more specific information one way to do so would be to do something like this:
ls -l /lib/x86_64-linux-gnu/libc.so.6
The output would likely show you that your path is a symbolic link, and the target of that link would be more informative. In this case I don't think you really need to know the exact version but having it would allow you to download matching glibc source if you see an error message from libc malloc and want to understand what it means.
So back to what that code shows you is that "victim" is set to point to the last entry of the doubly linked list for the arena recognized by av. It also shows you that the value at the end of the line is from "chunk2mem(victim)". In your case, with a 64 bit process, the macro chunk2mem is adding 16, so you can reconstruct the value of victim as 0x00000000051fc640-16 = 0x00000000051fc630.
You can look at what victim has by doing:
x/4gx 0x00000000051fc630
The second value shown will be the value of victim->size.
If you happen to have a core dump, you can probably use the free open source tool https://github.com/vmware/chap to gather more information because chap often detects such corruption at startup. To start it, use:
chap core-file-path
Given the likelihood that the size field is corrupted, it may also be helpful to understand how the adjacent allocation just prior to the one listed as 0x00000000051fc640 was being used. Possibly the corruption was due to a buffer overrun on that previous allocation. To see the contents of the previous allocation, type show allocation 51fc630 from the chap prompt. If chap tells you that the given address is not part of an allocation, use describe 51fc630 from the chap prompt to get an idea of what that allocation might be.
Before ruining the valgrind compile your program with adding -ggdb3 debug flag
gcc -o executable -std=c11 -Wall -ggdb3 main.c
To run valgrind, pass the executable as an argument
valgrind --leak-check=full \
--show-leak-kinds=all \
--track-origins=yes \
--verbose \
--log-file=valgrind-out.txt \
./executable
I'm use valgrind for detect many memory management bugs.
I just wrote a piece of CPP code and I compiled it using G++ in ubuntu.
When I run my code everything is fine, the code runs well and gives output but doesn't exit and it gives this error:
*** glibc detected *** ./a.out: free(): invalid next size (fast): 0x09f931f0 ***
======= Backtrace: =========
/lib/libc.so.6(+0x6c501)[0x3de501]
/lib/libc.so.6(+0x6dd70)[0x3dfd70]
/lib/libc.so.6(cfree+0x6d)[0x3e2e5d]
/usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0x6e2441]
./a.out[0x8049ce6]
/lib/libc.so.6(+0x2f69e)[0x3a169e]
/lib/libc.so.6(+0x2f70f)[0x3a170f]
/lib/libc.so.6(__libc_start_main+0xef)[0x388cef]
./a.out[0x8048a61]
======= Memory map: ========
00219000-0021a000 r-xp 00000000 00:00 0 [vdso]
00354000-00370000 r-xp 00000000 08:01 8781845 /lib/ld-2.12.1.so
00370000-00371000 r--p 0001b000 08:01 8781845 /lib/ld-2.12.1.so
00371000-00372000 rw-p 0001c000 08:01 8781845 /lib/ld-2.12.1.so
00372000-004c9000 r-xp 00000000 08:01 8781869 /lib/libc-2.12.1.so
004c9000-004ca000 ---p 00157000 08:01 8781869 /lib/libc-2.12.1.so
004ca000-004cc000 r--p 00157000 08:01 8781869 /lib/libc-2.12.1.so
004cc000-004cd000 rw-p 00159000 08:01 8781869 /lib/libc-2.12.1.so
004cd000-004d0000 rw-p 00000000 00:00 0
00638000-00717000 r-xp 00000000 08:01 3935829 /usr/lib/libstdc++.so.6.0.14
00717000-0071b000 r--p 000de000 08:01 3935829 /usr/lib/libstdc++.so.6.0.14
0071b000-0071c000 rw-p 000e2000 08:01 3935829 /usr/lib/libstdc++.so.6.0.14
0071c000-00723000 rw-p 00000000 00:00 0
00909000-0092d000 r-xp 00000000 08:01 8781918 /lib/libm-2.12.1.so
0092d000-0092e000 r--p 00023000 08:01 8781918 /lib/libm-2.12.1.so
0092e000-0092f000 rw-p 00024000 08:01 8781918 /lib/libm-2.12.1.so
00fdb000-00ff5000 r-xp 00000000 08:01 8781903 /lib/libgcc_s.so.1
00ff5000-00ff6000 r--p 00019000 08:01 8781903 /lib/libgcc_s.so.1
00ff6000-00ff7000 rw-p 0001a000 08:01 8781903 /lib/libgcc_s.so.1
08048000-0804b000 r-xp 00000000 08:01 8652645 /home/akg/Desktop/contest/a.out
0804b000-0804c000 r--p 00002000 08:01 8652645 /home/akg/Desktop/contest/a.out
0804c000-0804d000 rw-p 00003000 08:01 8652645 /home/akg/Desktop/contest/a.out
09f93000-09fb4000 rw-p 00000000 00:00 0 [heap]
b7600000-b7621000 rw-p 00000000 00:00 0
b7621000-b7700000 ---p 00000000 00:00 0
b7765000-b7768000 rw-p 00000000 00:00 0
b7775000-b7779000 rw-p 00000000 00:00 0
bf9a7000-bf9c8000 rw-p 00000000 00:00 0 [stack]
Aborted
What does this mean? How can i get rid of it?
I'm not using malloc or free , I'm just using vector!
Even if you're not allocating memory directly, it happens under the hood in vector code and you most likely corrupted some portion of memory by writing where you are not supposed to. The most likely reasons I can think of are:
Writing to an element that is out of bounds
Using a pointer/reference to an element that is no longer valid -- note that inserting more elements can invalidate earlier references
Of course, I can't say for sure unless you post some relevant code. Or try using valgrind to find the source of the problem.
This means you called free on a non valid pointer (ie: a pointer not allocated via malloc, or that you already freed).
Paste some code, else it's impossible to say why this happens.
So for a project i decided to make a sudoku solver that first uses finds naked singles (cells with only one possible value) and then just brute forces its way to victory.
This is my first time using multiple files in program and as such my first time using a makefile, but the errors i am getting aren't during compile time so i think my makefile is fine.
I tried debugging with GSB but it doesn't really seem to help all that much... If i had to guess i think te problem is occuring with my class Cell's destructor.
To give you a brief overview of the project so I dont just spit code at you:
The class puzzle contains a 9x9 matrix of the class Cell. The class Cell contains two integers to represent position on the board (row and column), an integer value (the actual value of the cell) and an array of 9 booleans that represent the possible candidates for the the value of the cell (0 in the array represents the value is not a possible candidate, 1 means it is) - so for example candidate[2] is the third value in the array, so if it was 1 it means that 3 is a possible value for the cell.
Now onto the code. My code is made up of 5 files: main.cpp, puzzle.cpp, cell.cpp, puzzle.h, and cell.h. Here is a link to my pastebin of the 5 files and the makefile.
I would advise you not pay attention to the huge functions in puzzle.cpp (checkConflicts() and eliminateCandidates()) as they are both just long if statements that make sure no cells conflict/elinimate confliction candidates.
The debugger jumps to the cell destructor that deletes the candidate array, but i don't see a problem with it!
Here is a copy of the error that i get after making and running the program:
$ make
g++ -c puzzle.cpp cell.h
g++ -c cell.cpp
g++ -o sudsolve main.cpp puzzle.o cell.o
$ ./sudsolve
*** Error in `./sudsolve': munmap_chunk(): invalid pointer: 0x0000000000a30fd4 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x7f576)[0x7fcaecc1f576]
./sudsolve[0x40bbdb]
./sudsolve[0x401cd2]
./sudsolve[0x402a12]
./sudsolve[0x402a84]
./sudsolve[0x402299]
./sudsolve[0x401e38]
./sudsolve[0x40156a]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7fcaecbc1ea5]
./sudsolve[0x400eb9]
======= Memory map: ========
00400000-0040e000 r-xp 00000000 fc:04 2097787 /home/silman/Documents/programming/ecs60/sudsolve/sudsolve
0060d000-0060e000 r--p 0000d000 fc:04 2097787 /home/silman/Documents/programming/ecs60/sudsolve/sudsolve
0060e000-0060f000 rw-p 0000e000 fc:04 2097787 /home/silman/Documents/programming/ecs60/sudsolve/sudsolve
00a30000-00a51000 rw-p 00000000 00:00 0 [heap]
7fcaec89b000-7fcaec99e000 r-xp 00000000 fc:04 1576781 /lib/x86_64-linux-gnu/libm-2.17.so
7fcaec99e000-7fcaecb9e000 ---p 00103000 fc:04 1576781 /lib/x86_64-linux-gnu/libm-2.17.so
7fcaecb9e000-7fcaecb9f000 r--p 00103000 fc:04 1576781 /lib/x86_64-linux-gnu/libm-2.17.so
7fcaecb9f000-7fcaecba0000 rw-p 00104000 fc:04 1576781 /lib/x86_64-linux-gnu/libm-2.17.so
7fcaecba0000-7fcaecd5e000 r-xp 00000000 fc:04 1576733 /lib/x86_64-linux-gnu/libc-2.17.so
7fcaecd5e000-7fcaecf5d000 ---p 001be000 fc:04 1576733 /lib/x86_64-linux-gnu/libc-2.17.so
7fcaecf5d000-7fcaecf61000 r--p 001bd000 fc:04 1576733 /lib/x86_64-linux-gnu/libc-2.17.so
7fcaecf61000-7fcaecf63000 rw-p 001c1000 fc:04 1576733 /lib/x86_64-linux-gnu/libc-2.17.so
7fcaecf63000-7fcaecf68000 rw-p 00000000 00:00 0
7fcaecf68000-7fcaecf7c000 r-xp 00000000 fc:04 1576758 /lib/x86_64-linux-gnu/libgcc_s.so.1
7fcaecf7c000-7fcaed17c000 ---p 00014000 fc:04 1576758 /lib/x86_64-linux-gnu/libgcc_s.so.1
7fcaed17c000-7fcaed17d000 r--p 00014000 fc:04 1576758 /lib/x86_64-linux-gnu/libgcc_s.so.1
7fcaed17d000-7fcaed17e000 rw-p 00015000 fc:04 1576758 /lib/x86_64-linux-gnu/libgcc_s.so.1
7fcaed17e000-7fcaed263000 r-xp 00000000 fc:04 271362 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.17
7fcaed263000-7fcaed462000 ---p 000e5000 fc:04 271362 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.17
7fcaed462000-7fcaed46a000 r--p 000e4000 fc:04 271362 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.17
7fcaed46a000-7fcaed46c000 rw-p 000ec000 fc:04 271362 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.17
7fcaed46c000-7fcaed481000 rw-p 00000000 00:00 0
7fcaed481000-7fcaed4a4000 r-xp 00000000 fc:04 1576709 /lib/x86_64-linux-gnu/ld-2.17.so
7fcaed684000-7fcaed689000 rw-p 00000000 00:00 0
7fcaed6a0000-7fcaed6a3000 rw-p 00000000 00:00 0
7fcaed6a3000-7fcaed6a4000 r--p 00022000 fc:04 1576709 /lib/x86_64-linux-gnu/ld-2.17.so
7fcaed6a4000-7fcaed6a6000 rw-p 00023000 fc:04 1576709 /lib/x86_64-linux-gnu/ld-2.17.so
7fff88ba8000-7fff88bc9000 rw-p 00000000 00:00 0 [stack]
7fff88bfe000-7fff88c00000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Aborted (core dumped)
The problem is that you call delete on a variable that wasn't allocated using new. For reference, here is the stripped Cell class from the pastebin:
class Cell{
public:
~Cell()
{
delete[] candidates;
}
private:
bool candidates[9];
};
The space for the candidates array is allocated together with your class, and it will automatically freed when your class is deleted (which happens automatically since its allocated on the stack). You only need to call delete for memory that was previously allocated using new.
I have a multithreaded program (Implemented in C using Pthreads on Linux platform) that runs on a multicore machine. I am using ValGrind with --memcheck option to find some memory issues that I have in my code. But it hangs. To give a complete overview of the problem, here is the background.
The code has some sequential part at the start as part of initialization and later it creates 8 threads (using Pthread API) and rungs to completion. My code dumps "core" after sometime. I used GDB, it gives the following trace.
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6[0xb7cd47cd]
/lib/tls/i686/cmov/libc.so.6(cfree+0x90)[0xb7cd7e30]
/home/kumar/CycleSim/slack_cp/sim-outorder[0x819a6c9]
/home/kumar/CycleSim/slack_cp/sim-outorder[0x8167e3e]
/home/kumar/CycleSim/slack_cp/sim-outorder[0x804f5e4]
/lib/tls/i686/cmov/libpthread.so.0[0xb7f8c31b]
/lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0xb7d3c57e]
======= Memory map: ========
08048000-081b5000 r-xp 00000000 08:11 11813248
/home/kumar/CycleSim/slack_cp/sim-outorder
081b5000-081b8000 rw-p 0016c000 08:11 11813248
/home/kumar/CycleSim/slack_cp/sim-outorder
081b8000-08549000 rw-p 081b8000 00:00 0 [heap]
ab9fd000-ab9fe000 ---p ab9fd000 00:00 0
ab9fe000-ac1fe000 rw-p ab9fe000 00:00 0
ac1fe000-ac1ff000 ---p ac1fe000 00:00 0
ac1ff000-ac9ff000 rw-p ac1ff000 00:00 0
ac9ff000-aca00000 ---p ac9ff000 00:00 0
aca00000-ad2cb000 rw-p aca00000 00:00 0
ad2cb000-ad300000 ---p ad2cb000 00:00 0
ad3bf000-ad3c0000 ---p ad3bf000 00:00 0
ad3c0000-adbc0000 rw-p ad3c0000 00:00 0
adbc0000-adbc1000 ---p adbc0000 00:00 0
adbc1000-ae3c1000 rw-p adbc1000 00:00 0
ae3c1000-ae3c2000 ---p ae3c1000 00:00 0
ae3c2000-aebc2000 rw-p ae3c2000 00:00 0
aebc2000-aebc3000 ---p aebc2000 00:00 0
aebc3000-b2e7d000 rw-p aebc3000 00:00 0
b2e7d000-b2e7e000 ---p b2e7d000 00:00 0
b2e7e000-b367e000 rw-p b2e7e000 00:00 0
b367e000-b367f000 ---p b367e000 00:00 0
b367f000-b7c6d000 rw-p b367f000 00:00 0
b7c6d000-b7da8000 r-xp 00000000 08:01 12895490 /lib/tls/i686/cmov/libc-2.5.so
b7da8000-b7da9000 r--p 0013b000 08:01 12895490 /lib/tls/i686/cmov/libc-2.5.so
b7da9000-b7dab000 rw-p 0013c000 08:01 12895490 /lib/tls/i686/cmov/libc-2.5.so
b7dab000-b7dae000 rw-p b7dab000 00:00 0
b7dae000-b7dde000 r-xp 00000000 08:21 3828021 /usr/lib/libgslcblas.so.0.0.0
b7dde000-b7ddf000 rw-p 0002f000 08:21 3828021 /usr/lib/libgslcblas.so.0.0.0
b7ddf000-b7f7d000 r-xp 00000000 08:21 3828022 /usr/lib/libgsl.so.0.9.0
b7f7d000-b7f87000 rw-p 0019d000 08:21 3828022 /usr/lib/libgsl.so.0.9.0
b7f87000-b7f9a000 r-xp 00000000 08:01 12895516
/lib/tls/i686/cmov/libpthread-2.5.so
b7f9a000-b7f9c000 rw-p 00013000 08:01 12895516
/lib/tls/i686/cmov/libpthread-2.5.so
b7f9c000-b7f9f000 rw-p b7f9c000 00:00 0
b7f9f000-b7fc4000 r-xp 00000000 08:01 12895498 /lib/tls/i686/cmov/libm-2.5.so
b7fc4000-b7fc6000 rw-p 00024000 08:01 12895498 /lib/tls/i686/cmov/libm-2.5.so
b7fc9000-b7fd4000 r-xp 00000000 08:01 12861504 /lib/libgcc_s.so.1
b7fd4000-b7fd5000 rw-p 0000a000 08:01 12861504 /lib/libgcc_s.so.1
b7fd5000-b7fd9000 rw-p b7fd5000 00:00 0
b7fd9000-b7ff2000 r-xp 00000000 08:01 12861461 /lib/ld-2.5.so
b7ff2000-b7ff4000 rw-p 00019000 08:01 12861461 /lib/ld-2.5.so
bf8a0000-bf8b5000 rw-p bf8a0000 00:00 0 [stack]
ffffe000-fffff000 r-xp 00000000 00:00 0 [vdso]
Though I used -g option and no O flags it does not give the exact code location where the problem exists. I
After searching over the internet I understood that, it comes because I am corrupting the memory. Either writing data in array out of bounds (Yes, I am using big array, but I am checking explicitly before accessing every element in the array) or accessing an illegal heap memory.
But as the code is huge, I could not figure it out just looking at it. So I turned to ValGrind for this to see where memory corruption is happening. I ran the code with ValGrind, it runs well till sequential part of the code, but when it comes to parallel part (Pthread creation part), It is not doing any thing. With the help of "top -H -p pid" I see that all threads are created, but they are in sleep mode. The original code (without valgrind) does not hang which I ran for a long time (But I cannot give guarantee that it is deadlock free). Is using Helgrind (Thread error detector of valgrind) any useful?
Can anyone point me to the document or similar issue. It is ValGrind version 2. Machine is i686, Linux operating system.
Thanks
D. L. Kumar
May be you can check this
valgrind stalls in multithreaded socket program
Valgrind forces application to run on single core, not sure if that can cause problems for your case.
I just wrote a piece of CPP code and I compiled it using G++ in ubuntu.
When I run my code everything is fine, the code runs well and gives output but doesn't exit and it gives this error:
*** glibc detected *** ./a.out: free(): invalid next size (fast): 0x09f931f0 ***
======= Backtrace: =========
/lib/libc.so.6(+0x6c501)[0x3de501]
/lib/libc.so.6(+0x6dd70)[0x3dfd70]
/lib/libc.so.6(cfree+0x6d)[0x3e2e5d]
/usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0x6e2441]
./a.out[0x8049ce6]
/lib/libc.so.6(+0x2f69e)[0x3a169e]
/lib/libc.so.6(+0x2f70f)[0x3a170f]
/lib/libc.so.6(__libc_start_main+0xef)[0x388cef]
./a.out[0x8048a61]
======= Memory map: ========
00219000-0021a000 r-xp 00000000 00:00 0 [vdso]
00354000-00370000 r-xp 00000000 08:01 8781845 /lib/ld-2.12.1.so
00370000-00371000 r--p 0001b000 08:01 8781845 /lib/ld-2.12.1.so
00371000-00372000 rw-p 0001c000 08:01 8781845 /lib/ld-2.12.1.so
00372000-004c9000 r-xp 00000000 08:01 8781869 /lib/libc-2.12.1.so
004c9000-004ca000 ---p 00157000 08:01 8781869 /lib/libc-2.12.1.so
004ca000-004cc000 r--p 00157000 08:01 8781869 /lib/libc-2.12.1.so
004cc000-004cd000 rw-p 00159000 08:01 8781869 /lib/libc-2.12.1.so
004cd000-004d0000 rw-p 00000000 00:00 0
00638000-00717000 r-xp 00000000 08:01 3935829 /usr/lib/libstdc++.so.6.0.14
00717000-0071b000 r--p 000de000 08:01 3935829 /usr/lib/libstdc++.so.6.0.14
0071b000-0071c000 rw-p 000e2000 08:01 3935829 /usr/lib/libstdc++.so.6.0.14
0071c000-00723000 rw-p 00000000 00:00 0
00909000-0092d000 r-xp 00000000 08:01 8781918 /lib/libm-2.12.1.so
0092d000-0092e000 r--p 00023000 08:01 8781918 /lib/libm-2.12.1.so
0092e000-0092f000 rw-p 00024000 08:01 8781918 /lib/libm-2.12.1.so
00fdb000-00ff5000 r-xp 00000000 08:01 8781903 /lib/libgcc_s.so.1
00ff5000-00ff6000 r--p 00019000 08:01 8781903 /lib/libgcc_s.so.1
00ff6000-00ff7000 rw-p 0001a000 08:01 8781903 /lib/libgcc_s.so.1
08048000-0804b000 r-xp 00000000 08:01 8652645 /home/akg/Desktop/contest/a.out
0804b000-0804c000 r--p 00002000 08:01 8652645 /home/akg/Desktop/contest/a.out
0804c000-0804d000 rw-p 00003000 08:01 8652645 /home/akg/Desktop/contest/a.out
09f93000-09fb4000 rw-p 00000000 00:00 0 [heap]
b7600000-b7621000 rw-p 00000000 00:00 0
b7621000-b7700000 ---p 00000000 00:00 0
b7765000-b7768000 rw-p 00000000 00:00 0
b7775000-b7779000 rw-p 00000000 00:00 0
bf9a7000-bf9c8000 rw-p 00000000 00:00 0 [stack]
Aborted
What does this mean? How can i get rid of it?
I'm not using malloc or free , I'm just using vector!
Even if you're not allocating memory directly, it happens under the hood in vector code and you most likely corrupted some portion of memory by writing where you are not supposed to. The most likely reasons I can think of are:
Writing to an element that is out of bounds
Using a pointer/reference to an element that is no longer valid -- note that inserting more elements can invalidate earlier references
Of course, I can't say for sure unless you post some relevant code. Or try using valgrind to find the source of the problem.
This means you called free on a non valid pointer (ie: a pointer not allocated via malloc, or that you already freed).
Paste some code, else it's impossible to say why this happens.