I just want to know where is (if present!) the Heap of my bash process (pid = 16457) in the result of cat /proc/16457/maps
0078a000-007a0000 r-xp 00000000 08:02 1319336 /lib/ld-2.3.4.so
007a0000-007a1000 r--p 00015000 08:02 1319336 /lib/ld-2.3.4.so
007a1000-007a2000 rw-p 00016000 08:02 1319336 /lib/ld-2.3.4.so
007a9000-008cf000 r-xp 00000000 08:02 1384495 /lib/tls/libc-2.3.4.so
008cf000-008d1000 r--p 00125000 08:02 1384495 /lib/tls/libc-2.3.4.so
008d1000-008d3000 rw-p 00127000 08:02 1384495 /lib/tls/libc-2.3.4.so
008d3000-008d5000 rw-p 008d3000 00:00 0
008fc000-008fe000 r-xp 00000000 08:02 1319337 /lib/libdl-2.3.4.so
008fe000-008ff000 r--p 00001000 08:02 1319337 /lib/libdl-2.3.4.so
008ff000-00900000 rw-p 00002000 08:02 1319337 /lib/libdl-2.3.4.so
00b27000-00b2a000 r-xp 00000000 08:02 278109 /lib/libtermcap.so.2.0.8
00b2a000-00b2b000 rw-p 00002000 08:02 278109 /lib/libtermcap.so.2.0.8
08047000-080d8000 r-xp 00000000 08:02 902412 /bin/bash
080d8000-080de000 rw-p 00090000 08:02 902412 /bin/bash
080de000-080e3000 rw-p 080de000 00:00 0
09ceb000-09d25000 rw-p 09ceb000 00:00 0
b7d99000-b7d9b000 rw-p b7d99000 00:00 0
b7d9b000-b7da1000 r--s 00000000 08:02 130808 /usr/lib/gconv/gconv-modules.cache
b7da1000-b7dd6000 r--s 00000000 08:02 869910 /var/db/nscd/passwd
b7dd6000-b7fd6000 r--p 00000000 08:02 101088 /usr/lib/locale/locale-archive
b7fd6000-b7fd8000 rw-p b7fd6000 00:00 0
bff07000-c0000000 rw-p bff07000 00:00 0
ffffe000-fffff000 r-xp 00000000 00:00 0
"The" heap most people refer to is this line:
080de000-080e3000 rw-p 080de000 00:00 0
i.e. it's the region of memory created and expandable by the brk syscall, immediately following the main program's .data and .bss segments.
One might also consider the following as part of the "heap":
09ceb000-09d25000 rw-p 09ceb000 00:00 0
It seems to be an anonymous mapping created by mmap to service a large malloc request. Most malloc implementations use mmap for large requests so they can munmap it on free and return the whole block of memory to the OS. It also makes calloc much faster since you're guaranteed to get per-zeroed pages this way.
The heap is clearly marked as [heap] in current Linux versions. Your listing doesn't show it. Are you sure you didn't accidentally cut it out when copying it to your question?
On my shell:
~% grep '\[heap' /proc/$$/maps
00bca000-00d2e000 rw-p 00000000 00:00 0 [heap]
The heap usually appears to be marked with [heap] when a malloc call is called; however, you'll notice that if you keep growing the heap with multiple lines of malloc() code that range will not grow; however, new blank line entries will be created.
Related
I'm getting the familiar free(): invalid pointer error. In trying to debug, I ended up commenting out each free() in my code, one by one, until there were none left and I'm still getting this runtime error. Has anyone else run into a similar issue?
By the way - it's difficult for me to debug this using gdb, because the entire server doesn't actually crash when the error message is printed, just the particular forked process that was handling the single client.
Thank you.
==============================
*** glibc detected *** ./server: free(): invalid pointer: 0x08641a38 ***
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(+0x6b961)[0xefe961]
/lib/i386-linux-gnu/libc.so.6(+0x6d28b)[0xf0028b]
/lib/i386-linux-gnu/libc.so.6(cfree+0x6d)[0xf0341d]
/usr/lib/i386-linux-gnu/libstdc++.so.6(_ZdlPv+0x21)[0x4c74d1]
./server[0x804b499]
./server[0x804b2ad]
./server[0x804aecd]
./server[0x804ad36]
./server[0x804a3a3]
/lib/i386-linux-gnu/libc.so.6(+0x2fa6f)[0xec2a6f]
/lib/i386-linux-gnu/libc.so.6(+0x2facf)[0xec2acf]
./server[0x804966b]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0xea9e37]
./server[0x8049331]
======= Memory map: ========
00338000-00352000 r-xp 00000000 08:01 394236 /lib/i386-linux-gnu/libgcc_s.so.1
00352000-00353000 r--p 00019000 08:01 394236 /lib/i386-linux-gnu/libgcc_s.so.1
00353000-00354000 rw-p 0001a000 08:01 394236 /lib/i386-linux-gnu/libgcc_s.so.1
003c1000-003c2000 r-xp 00000000 00:00 0 [vdso]
0041d000-004fc000 r-xp 00000000 08:01 792946 /usr/lib/i386-linux-gnu/libstdc++.so.6.0.14
004fc000-00500000 r--p 000de000 08:01 792946 /usr/lib/i386-linux-gnu/libstdc++.so.6.0.14
00500000-00501000 rw-p 000e2000 08:01 792946 /usr/lib/i386-linux-gnu/libstdc++.so.6.0.14
00501000-00508000 rw-p 00000000 00:00 0
00664000-00688000 r-xp 00000000 08:01 394245 /lib/i386-linux-gnu/libm-2.13.so
00688000-00689000 r--p 00023000 08:01 394245 /lib/i386-linux-gnu/libm-2.13.so
00689000-0068a000 rw-p 00024000 08:01 394245 /lib/i386-linux-gnu/libm-2.13.so
00793000-007af000 r-xp 00000000 08:01 394195 /lib/i386-linux-gnu/ld-2.13.so
007af000-007b0000 r--p 0001b000 08:01 394195 /lib/i386-linux-gnu/ld-2.13.so
007b0000-007b1000 rw-p 0001c000 08:01 394195 /lib/i386-linux-gnu/ld-2.13.so
00960000-0096a000 r-xp 00000000 08:01 394254 /lib/i386-linux-gnu/libnss_files-2.13.so
0096a000-0096b000 r--p 00009000 08:01 394254 /lib/i386-linux-gnu/libnss_files-2.13.so
0096b000-0096c000 rw-p 0000a000 08:01 394254 /lib/i386-linux-gnu/libnss_files-2.13.so
00e93000-00fed000 r-xp 00000000 08:01 394208 /lib/i386-linux-gnu/libc-2.13.so
00fed000-00fee000 ---p 0015a000 08:01 394208 /lib/i386-linux-gnu/libc-2.13.so
00fee000-00ff0000 r--p 0015a000 08:01 394208 /lib/i386-linux-gnu/libc-2.13.so
00ff0000-00ff1000 rw-p 0015c000 08:01 394208 /lib/i386-linux-gnu/libc-2.13.so
00ff1000-00ff4000 rw-p 00000000 00:00 0
08048000-08056000 r-xp 00000000 08:01 1084793 /home/mwrosen/cpe464/prog2/server
08056000-08057000 r--p 0000d000 08:01 1084793 /home/mwrosen/cpe464/prog2/server
08057000-08058000 rw-p 0000e000 08:01 1084793 /home/mwrosen/cpe464/prog2/server
08641000-08662000 rw-p 00000000 00:00 0 [heap]
b7600000-b7621000 rw-p 00000000 00:00 0
b7621000-b7700000 ---p 00000000 00:00 0
b7718000-b771b000 rw-p 00000000 00:00 0
b7729000-b772c000 rw-p 00000000 00:00 0
bfacf000-bfaf0000 rw-p 00000000 00:00 0 [stack]
If your code trashes a pointer used by some other code, other code may wind up calling free on an invalid pointer. Likely you are accessing some memory you don't own.
There are many ways this can happen, here are two common ones:
1) If you declare an array like int f[7];, the last array element is f[6]. Modifying f[7] can corrupt someone else's memory.
2) If you save a pointer to an object allocated on the stack, that object goes out of scope, and then you modify something through that pointer, you can corrupt someone else's memory.
Try to use valgrind to debug your issue.
If your error persist even with all free removed, it could be because some code is overflowing its memory zone (e.g. a buffer overflow).
This question already has answers here:
When / How does Linux load shared libraries into address space?
(5 answers)
Closed 9 years ago.
On linux platform,
Could anyone tell me where is the dynamic library in the memory?
I learned that the dynamic library are mmap to the process according to the GOT
of this process,
is that true?
Thank you!
You can see where things got mapped in a Linux process by looking in /proc/pid/maps -- all you need to know is the process id. For example:
$ cat /proc/self/maps
00400000-0040b000 r-xp 00000000 08:01 71827604 /bin/cat
0060a000-0060b000 r--p 0000a000 08:01 71827604 /bin/cat
0060b000-0060c000 rw-p 0000b000 08:01 71827604 /bin/cat
00690000-006b1000 rw-p 00000000 00:00 0 [heap]
7f07fbaf7000-7f07fbdc0000 r--p 00000000 08:01 18094104 /usr/lib/locale/locale-archive
7f07fbdc0000-7f07fbf75000 r-xp 00000000 08:01 14552996 /lib/x86_64-linux-gnu/libc-2.15.so
7f07fbf75000-7f07fc175000 ---p 001b5000 08:01 14552996 /lib/x86_64-linux-gnu/libc-2.15.so
7f07fc175000-7f07fc179000 r--p 001b5000 08:01 14552996 /lib/x86_64-linux-gnu/libc-2.15.so
7f07fc179000-7f07fc17b000 rw-p 001b9000 08:01 14552996 /lib/x86_64-linux-gnu/libc-2.15.so
7f07fc17b000-7f07fc180000 rw-p 00000000 00:00 0
7f07fc180000-7f07fc1a2000 r-xp 00000000 08:01 14553008 /lib/x86_64-linux-gnu/ld-2.15.so
7f07fc37e000-7f07fc381000 rw-p 00000000 00:00 0
7f07fc3a0000-7f07fc3a2000 rw-p 00000000 00:00 0
7f07fc3a2000-7f07fc3a3000 r--p 00022000 08:01 14553008 /lib/x86_64-linux-gnu/ld-2.15.so
7f07fc3a3000-7f07fc3a5000 rw-p 00023000 08:01 14553008 /lib/x86_64-linux-gnu/ld-2.15.so
7fff90e28000-7fff90e49000 rw-p 00000000 00:00 0 [stack]
7fff90f1f000-7fff90f20000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
shows everything that got mapped in to run the cat program.
In a complex program, I am encountering a stack smashing error, pasted below. I'm having trouble to find out where it happens. I located the function using printf-debugging, and noticed that the check actually happens during function return (the printf just before the return is executed, the one just after the function call is not).
However, it's a huge function; I've read it all, but didn't notice any stack overflow opportunities in it. I therefore need a better estimate of where the bug is. How can I debug this further?
I think it would be easiest if I could add a debugger watchpoint on the stack smashing detection memory, so it interrupts execution at the time of smashing instead of at function return. If so, how can I know which memory this is?
For those who want to see source, I recommend looking at any of the stack smashing questions here on Stack Overflow. If you really want to see the code I'm using, get the freedink source (the offending function is updateFrame).
Update
On the gcc-patches list, this issue was discussed in 2009. It doesn't seem to have reached a conclusion though. At least I don't see any name come up when I say "info locals" in gdb (as is suggested somewhere in that thread). If someone can tell me how to find this __stack_guard__ (which isn't working, as it was sort-of rejected), that would answer my question.
Next update
Ok, after lots of searching, I found something completely unexpected. As you can see from the stack backtrace, the stack smashing is detected when exiting a libSDL function. Now normally SDL functions work fine, and freedink is full of bugs. So I didn't even think I could have hit a bug in SDL. However, it seems I did. It is trying to play a midi file. If I copy a different midi file to its place, the program works fine.
So my current problem is solved, but my question is still not answered. Although the stack backtrace does point to the function where the stack is smashed (so it is more useful than I thought), it doesn't provide an address for the guard, which may be useful as well (for setting a watchpoint).
*** stack smashing detected ***: freedink terminated
======= Backtrace: =========
/lib/i386-linux-gnu/i686/cmov/libc.so.6(__fortify_fail+0x50)[0xb754c3f0]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(+0xea39a)[0xb754c39a]
/usr/lib/i386-linux-gnu/libSDL_mixer-1.2.so.0(+0x1c524)[0xb771f524]
/usr/lib/i386-linux-gnu/libSDL_mixer-1.2.so.0(+0x17443)[0xb771a443]
======= Memory map: ========
08048000-0808b000 r-xp 00000000 08:02 4333161 /usr/games/freedink
0808b000-0808c000 rw-p 00042000 08:02 4333161 /usr/games/freedink
0808c000-0841d000 rw-p 00000000 00:00 0
09fa9000-0b2de000 rw-p 00000000 00:00 0 [heap]
afda8000-b09e5000 rw-p 00000000 00:00 0
b0a00000-b0a21000 rw-p 00000000 00:00 0
b0a21000-b0b00000 ---p 00000000 00:00 0
b0ba7000-b0bc3000 r-xp 00000000 08:02 6422698 /lib/i386-linux-gnu/libgcc_s.so.1
b0bc3000-b0bc4000 rw-p 0001b000 08:02 6422698 /lib/i386-linux-gnu/libgcc_s.so.1
b0bea000-b0bec000 rw-p 00000000 00:00 0
b0bec000-b0bed000 r--p 00000000 08:02 4361451 /usr/share/locale/nl/LC_MESSAGES/freedink.mo
b0bed000-b0e69000 rw-p 00000000 00:00 0
b0ea2000-b127f000 rw-p 00000000 00:00 0
b12d7000-b12f0000 rw-p 00000000 00:00 0
b130e000-b1330000 r--p 00000000 08:02 4348594 /usr/share/locale/nl/LC_MESSAGES/libc.mo
b13a1000-b13dd000 rw-p 00000000 00:00 0
b13fa000-b13fb000 ---p 00000000 00:00 0
b13fb000-b1bfb000 rw-p 00000000 00:00 0
b1bfb000-b1c05000 r--p 00000000 08:02 4355730 /usr/share/locale/nl/LC_MESSAGES/pulseaudio.mo
b1c05000-b5c06000 rw-s 00000000 00:11 1297260 /run/shm/pulse-shm-3619928632
b5c06000-b5c9f000 rw-p 00000000 00:00 0
b5c9f000-b5dcb000 rw-s 00000000 00:04 1900555 /SYSV00000000 (deleted)
b5dcb000-b5e22000 rw-p 00000000 00:00 0
b5e35000-b5ecd000 rw-p 00000000 00:00 0
b5ecd000-b5ed2000 r-xp 00000000 08:02 4332397 /usr/lib/i386-linux-gnu/libXfixes.so.3.1.0
b5ed2000-b5ed3000 rw-p 00004000 08:02 4332397 /usr/lib/i386-linux-gnu/libXfixes.so.3.1.0
b5ed3000-b5edb000 r-xp 00000000 08:02 4342806 /usr/lib/i386-linux-gnu/libXrender.so.1.3.0
b5edb000-b5edc000 rw-p 00008000 08:02 4342806 /usr/lib/i386-linux-gnu/libXrender.so.1.3.0
b5edc000-b5ee5000 r-xp 00000000 08:02 4336027 /usr/lib/i386-linux-gnu/libXcursor.so.1.0.2
b5ee5000-b5ee6000 rw-p 00009000 08:02 4336027 /usr/lib/i386-linux-gnu/libXcursor.so.1.0.2
b5ee6000-b5ee7000 ---p 00000000 00:00 0
b5ee7000-b66e7000 rw-p 00000000 00:00 0
b66e7000-b685e000 r--p 00000000 08:02 4338396 /usr/lib/locale/locale-archive
b685e000-b6862000 rw-p 00000000 00:00 0
b6862000-b6872000 r-xp 00000000 08:02 6554164 /lib/i386-linux-gnu/i686/cmov/libresolv-2.13.so
b6872000-b6873000 r--p 00010000 08:02 6554164 /lib/i386-linux-gnu/i686/cmov/libresolv-2.13.so
b6873000-b6874000 rw-p 00011000 08:02 6554164 /lib/i386-linux-gnu/i686/cmov/libresolv-2.13.so
b6874000-b6876000 rw-p 00000000 00:00 0
b6876000-b69dc000 r-xp 00000000 08:02 4327161 /usr/lib/i386-linux-gnu/libvorbisenc.so.2.0.8
b69dc000-b69ed000 r--p 00165000 08:02 4327161 /usr/lib/i386-linux-gnu/libvorbisenc.so.2.0.8
b69ed000-b69ee000 rw-p 00176000 08:02 4327161 /usr/lib/i386-linux-gnu/libvorbisenc.so.2.0.8
b69ee000-b69ef000 rw-p 00000000 00:00 0
b69ef000-b6a02000 r-xp 00000000 08:02 6554172 /lib/i386-linux-gnu/i686/cmov/libnsl-2.13.so
b6a02000-b6a03000 r--p 00012000 08:02 6554172 /lib/i386-linux-gnu/i686/cmov/libnsl-2.13.so
b6a03000-b6a04000 rw-p 00013000 08:02 6554172 /lib/i386-linux-gnu/i686/cmov/libnsl-2.13.so
b6a04000-b6a06000 rw-p 00000000 00:00 0
b6a06000-b6a14000 r-xp 00000000 08:02 4334619 /usr/lib/i386-linux-gnu/libXi.so.6.1.0
b6a14000-b6a15000 rw-p 0000d000 08:02 4334619 /usr/lib/i386-linux-gnu/libXi.so.6.1.0
b6a15000-b6a19000 r-xp 00000000 08:02 6422575 /lib/i386-linux-gnu/libuuid.so.1.3.0
b6a19000-b6a1a000 r--p 00003000 08:02 6422575 /lib/i386-linux-gnu/libuuid.so.1.3.0
b6a1a000-b6a1b000 rw-p 00004000 08:02 6422575 /lib/i386-linux-gnu/libuuid.so.1.3.0
b6a1b000-b6a20000 r-xp 00000000 08:02 4331837 /usr/lib/i386-linux-gnu/libXdmcp.so.6.0.0
b6a20000-b6a21000 rw-p 00004000 08:02 4331837 /usr/lib/i386-linux-gnu/libXdmcp.so.6.0.0
b6a21000-b6a23000 r-xp 00000000 08:02 4330387 /usr/lib/i386-linux-gnu/libXau.so.6.0.0
b6a23000-b6a24000 rw-p 00001000 08:02 4330387 /usr/lib/i386-linux-gnu/libXau.so.6.0.0
b6a24000-b6a25000 rw-p 00000000 00:00 0
b6a25000-b6a29000 r-xp 00000000 08:02 6423604 /lib/i386-linux-gnu/libattr.so.1.1.0
b6a29000-b6a2a000 r--p 00003000 08:02 6423604 /lib/i386-linux-gnu/libattr.so.1.1.0
b6a2a000-b6a2b000 rw-p 00004000 08:02 6423604 /lib/i386-linux-gnu/libattr.so.1.1.0
b6a2b000-b6a30000 r-xp 00000000 08:02 4331630 /usr/lib/i386-linux-gnu/libasyncns.so.0.3.1
b6a30000-b6a31000 rw-p 00004000 08:02 4331630 /usr/lib/i386-linux-gnu/libasyncns.so.0.3.1
b6a31000-b6a9e000 r-xp 00000000 08:02 4375323 /usr/lib/i386-linux-gnu/libsndfile.so.1.0.25
b6a9e000-b6aa0000 r--p 0006c000 08:02 4375323 /usr/lib/i386-linux-gnu/libsndfile.so.1.0.25
b6aa0000-b6aa1000 rw-p 0006e000 08:02 4375323 /usr/lib/i386-linux-gnu/libsndfile.so.1.0.25
b6aa1000-b6aa5000 rw-p 00000000 00:00 0
b6aa5000-b6aad000 r-xp 00000000 08:02 6422615 /lib/i386-linux-gnu/libwrap.so.0.7.6
b6aad000-b6aae000 r--p 00007000 08:02 6422615 /lib/i386-linux-gnu/libwrap.so.0.7.6
b6aae000-b6aaf000 rw-p 00008000 08:02 6422615 /lib/i386-linux-gnu/libwrap.so.0.7.6
b6aaf000-b6ab4000 r-xp 00000000 08:02 4331851 /usr/lib/i386-linux-gnu/libXtst.so.6.1.0
b6ab4000-b6ab5000 rw-p 00004000 08:02 4331851 /usr/lib/i386-linux-gnu/libXtst.so.6.1.0
b6ab5000-b6ab6000 rw-p 00000000 00:00 0
b6ab6000-b6abd000 r-xp 00000000 08:02 4332239 /usr/lib/i386-linux-gnu/libSM.so.6.0.1
b6abd000-b6abe000 rw-p 00006000 08:02 4332239 /usr/lib/i386-linux-gnu/libSM.so.6.0.1
b6abe000-b6ad4000 r-xp 00000000 08:02 4332225 /usr/lib/i386-linux-gnu/libICE.so.6.3.0
b6ad4000-b6ad6000 rw-p 00015000 08:02 4332225 /usr/lib/i386-linux-gnu/libICE.so.6.3.0
b6ad6000-b6ad7000 rw-p 00000000 00:00 0
b6ad7000-b6ad8000 r-xp 00000000 08:02 4326690 /usr/lib/i386-linux-gnu/libX11-xcb.so.1.0.0
b6ad8000-b6ad9000 rw-p 00000000 08:02 4326690 /usr/lib/i386-linux-gnu/libX11-xcb.so.1.0.0
b6ad9000-b6af6000 r-xp 00000000 08:02 6423599 /lib/i386-linux-gnu/libtinfo.so.5.9
b6af6000-b6af8000 r--p 0001c000 08:02 6423599 /lib/i386-linux-gnu/libtinfo.so.5.9
b6af8000-b6af9000 rw-p 0001e000 08:02 6423599 /lib/i386-linux-gnu/libtinfo.so.5.9
b6af9000-b6b2a000 r-xp 00000000 08:02 6423581 /lib/i386-linux-gnu/libncursesw.so.5.9
b6b2a000-b6b2b000 r--p 00030000 08:02 6423581 /lib/i386-linux-gnu/libncursesw.so.5.9
b6b2b000-b6b2c000 rw-p 00031000 08:02 6423581 /lib/i386-linux-gnu/libncursesw.so.5.9
b6b2c000-b6b2d000 rw-p 00000000 00:00 0
b6b2d000-b6c15000 r-xp 00000000 08:02 6423605 /lib/i386-linux-gnu/libslang.so.2.2.4
b6c15000-b6c17000 r--p 000e8000 08:02 6423605 /lib/i386-linux-gnu/libslang.so.2.2.4
b6c17000-b6c26000 rw-p 000ea000 08:02 6423605 /lib/i386-linux-gnu/libslang.so.2.2.4
b6c26000-b6c60000 rw-p 00000000 00:00 0
b6c60000-b6c81000 r-xp 00000000 08:02 4331073 /usr/lib/i386-linux-gnu/libxcb.so.1.1.0
b6c81000-b6c82000 r--p 00020000 08:02 4331073 /usr/lib/i386-linux-gnu/libxcb.so.1.1.0
b6c82000-b6c83000 rw-p 00021000 08:02 4331073 /usr/lib/i386-linux-gnu/libxcb.so.1.1.0
b6c83000-b6ccc000 r-xp 00000000 08:02 6422562 /lib/i386-linux-gnu/libdbus-1.so.3.7.2
b6ccc000-b6ccd000 ---p 00049000 08:02 6422562 /lib/i386-linux-gnu/libdbus-1.so.3.7.2
b6ccd000-b6cce000 r--p 00049000 08:02 6422562 /lib/i386-linux-gnu/libdbus-1.so.3.7.2
b6cce000-b6ccf000 rw-p 0004a000 08:02 6422562 /lib/i386-linux-gnu/libdbus-1.so.3.7.2
b6ccf000-b6cd7000 r-xp 00000000 08:02 4327592 /usr/lib/i386-linux-gnu/libjson.so.0.1.0
b6cd7000-b6cd8000 r--p 00007000 08:02 4327592 /usr/lib/i386-linux-gnu/libjson.so.0.1.0
b6cd8000-b6cd9000 rw-p 00008000 08:02 4327592 /usr/lib/i386-linux-gnu/libjson.so.0.1.0
b6cd9000-b6cdd000 r-xp 00000000 08:02 6423193 /lib/i386-linux-gnu/libcap.so.2.22
b6cdd000-b6cde000 rw-p 00003000 08:02 6423193 /lib/i386-linux-gnu/libcap.so.2.22
b6cde000-b6cdf000 rw-p 00000000 00:00 0
b6cdf000-b6d45000 r-xp 00000000 08:02 4339765 /usr/lib/i386-linux-gnu/pulseaudio/libpulsecommon-2.0.so
b6d45000-b6d46000 r--p 00065000 08:02 4339765 /usr/lib/i386-linux-gnu/pulseaudio/libpulsecommon-2.0.so
b6d46000-b6d47000 rw-p 00066000 08:02 4339765 /usr/lib/i386-linux-gnu/pulseaudio/libpulsecommon-2.0.so
b6d47000-b6d4e000 r-xp 00000000 08:02 6554189 /lib/i386-linux-gnu/i686/cmov/librt-2.13.so
b6d4e000-b6d4f000 r--p 00006000 08:02 6554189 /lib/i386-linux-gnu/i686/cmov/librt-2.13.so
b6d4f000-b6d50000 rw-p 00007000 08:02 6554189 /lib/i386-linux-gnu/i686/cmov/librt-2.13.so
b6d50000-b6d5b000 r-xp 00000000 08:02 4330586 /usr/lib/i386-linux-gnu/libjbig.so.0.0.0
b6d5b000-b6d5e000 rw-p 0000b000 08:02 4330586 /usr/lib/i386-linux-gnu/libjbig.so.0.0.0
b6d5e000-b6d64000 r-xp 00000000 08:02 4333085 /usr/lib/i386-linux-gnu/libogg.so.0.8.0
b6d64000-b6d65000 rw-p 00005000 08:02 4333085 /usr/lib/i386-linux-gnu/libogg.so.0.8.0
b6d65000-b6d66000 rw-p 00000000 00:00 0
b6d66000-b6d8c000 r-xp 00000000 08:02 6426268 /lib/i386-linux-gnu/libexpat.so.1.6.0
b6d8c000-b6d8d000 ---p 00026000 08:02 6426268 /lib/i386-linux-gnu/libexpat.so.1.6.0
b6d8d000-b6d8f000 r--p 00026000 08:02 6426268 /lib/i386-linux-gnu/libexpat.so.1.6.0
b6d8f000-b6d90000 rw-p 00028000 08:02 6426268 /lib/i386-linux-gnu/libexpat.so.1.6.0
b6d90000-b6da5000 r-xp 00000000 08:02 6553829 /lib/i386-linux-gnu/i686/cmov/libpthread-2.13.so
b6da5000-b6da6000 r--p 00014000 08:02 6553829 /lib/i386-linux-gnu/i686/cmov/libpthread-2.13.so
b6da6000-b6da7000 rw-p 00015000 08:02 6553829 /lib/i386-linux-gnu/i686/cmov/libpthread-2.13.so
b6da7000-b6da9000 rw-p 00000000 00:00 0
b6da9000-b6dab000 r-xp 00000000 08:02 4338554 /usr/lib/i386-linux-gnu/libts-0.0.so.0.1.1
b6dab000-b6dac000 rw-p 00001000 08:02 4338554 /usr/lib/i386-linux-gnu/libts-0.0.so.0.1.1
b6dac000-b6e73000 r-xp 00000000 08:02 4326574 /usr/lib/i386-linux-gnu/libcaca.so.0.99.18
b6e73000-b6e74000 rw-p 000c6000 08:02 4326574 /usr/lib/i386-linux-gnu/libcaca.so.0.99.18
b6e74000-b6e79000 rw-p 00000000 00:00 0
b6e79000-b6e8f000 r-xp 00000000 08:02 4353038 /usr/lib/i386-linux-gnu/libdirect-1.2.so.9.0.1
b6e8f000-b6e90000 rw-p 00016000 08:02 4353038 /usr/lib/i386-linux-gnu/libdirect-1.2.so.9.0.1
b6e90000-b6e91000 rw-p 00000000 00:00 0
b6e91000-b6e9a000 r-xp 00000000 08:02 4353034 /usr/lib/i386-linux-gnu/libfusion-1.2.so.9.0.1
b6e9a000-b6e9b000 rw-p 00008000 08:02 4353034 /usr/lib/i386-linux-gnu/libfusion-1.2.so.9.0.1
b6e9b000-b6f1e000 r-xp 00000000 08:02 4353040 /usr/lib/i386-linux-gnu/libdirectfb-1.2.so.9.0.1
b6f1e000-b6f21000 rw-p 00082000 08:02 4353040 /usr/lib/i386-linux-gnu/libdirectfb-1.2.so.9.0.1
b6f21000-b6f32000 r-xp 00000000 08:02 4325458 /usr/lib/i386-linux-gnu/libXext.so.6.4.0
b6f32000-b6f33000 rw-p 00010000 08:02 4325458 /usr/lib/i386-linux-gnu/libXext.so.6.4.0
b6f33000-b7067000 r-xp 00000000 08:02 4327567 /usr/lib/i386-linux-gnu/libX11.so.6.3.0
b7067000-b706b000 rw-p 00133000 08:02 4327567 /usr/lib/i386-linux-gnu/libX11.so.6.3.0
b706b000-b70b9000 r-xp 00000000 08:02 4339764 /usr/lib/i386-linux-gnu/libpulse.so.0.14.2
b70b9000-b70ba000 r--p 0004d000 08:02 4339764 /usr/lib/i386-linux-gnu/libpulse.so.0.14.2
b70ba000-b70bb000 rw-p 0004e000 08:02 4339764 /usr/lib/i386-linux-gnu/libpulse.so.0.14.2
b70bb000-b70bc000 rw-p 00000000 00:00 0
b70bc000-b70bf000 r-xp 00000000 08:02 4330214 /usr/lib/i386-linux-gnu/libpulse-simple.so.0.0.3
b70bf000-b70c0000 r--p 00002000 08:02 4330214 /usr/lib/i386-linux-gnu/libpulse-simple.so.0.0.3
b70c0000-b70c1000 rw-p 00003000 08:02 4330214 /usr/lib/i386-linux-gnu/libpulse-simple.so.0.0.3
b70c1000-b71b4000 r-xp 00000000 08:02 4328460 /usr/lib/i386-linux-gnu/libasound.so.2.0.0
b71b4000-b71b8000 r--p 000f2000 08:02 4328460 /usr/lib/i386-linux-gnu/libasound.so.2.0.0
b71b8000-b71b9000 rw-p 000f6000 08:02 4328460 /usr/lib/i386-linux-gnu/libasound.so.2.0.0
b71b9000-b7250000 r-xp 00000000 08:02 4330930 /usr/lib/i386-linux-gnu/libfreetype.so.6.8.1
b7250000-b7254000 r--p 00096000 08:02 4330930 /usr/lib/i386-linux-gnu/libfreetype.so.6.8.1
b7254000-b7255000 rw-p 0009a000 08:02 4330930 /usr/lib/i386-linux-gnu/libfreetype.so.6.8.1
b7255000-b7283000 r-xp 00000000 08:02 4327431 /usr/lib/i386-linux-gnu/libwebp.so.2.0.0
b7283000-b7284000 r--p 0002d000 08:02 4327431 /usr/lib/i386-linux-gnu/libwebp.so.2.0.0
b7284000-b7285000 rw-p 0002e000 08:02 4327431 /usr/lib/i386-linux-gnu/libwebp.so.2.0.0
b7285000-b7288000 rw-p 00000000 00:00 0
b7288000-b729f000 r-xp 00000000 08:02 6422674 /lib/i386-linux-gnu/libz.so.1.2.7
b729f000-b72a0000 r--p 00016000 08:02 6422674 /lib/i386-linux-gnu/libz.so.1.2.7
b72a0000-b72a1000 rw-p 00017000 08:02 6422674 /lib/i386-linux-gnu/libz.so.1.2.7
b72a1000-b72a2000 rw-p 00000000 00:00 0
b72a2000-b7304000 r-xp 00000000 08:02 4328894 /usr/lib/i386-linux-gnu/libtiff.so.4.3.6
b7304000-b7305000 ---p 00062000 08:02 4328894 /usr/lib/i386-linux-gnu/libtiff.so.4.3.6
b7305000-b7307000 r--p 00062000 08:02 4328894 /usr/lib/i386-linux-gnu/libtiff.so.4.3.6
b7307000-b7308000 rw-p 00064000 08:02 4328894 /usr/lib/i386-linux-gnu/libtiff.so.4.3.6
b7308000-b7340000 r-xp 00000000 08:02 4325500 /usr/lib/i386-linux-gnu/libjpeg.so.8.4.0
b7340000-b7341000 rw-p 00037000 08:02 4325500 /usr/lib/i386-linux-gnu/libjpeg.so.8.4.0
b7341000-b7369000 r-xp 00000000 08:02 6422719 /lib/i386-linux-gnu/libpng12.so.0.49.0
b7369000-b736a000 r--p 00027000 08:02 6422719 /lib/i386-linux-gnu/libpng12.so.0.49.0
b736a000-b736b000 rw-p 00028000 08:02 6422719 /lib/i386-linux-gnu/libpng12.so.0.49.0
b736b000-b7381000 r-xp 00000000 08:02 4334103 /usr/lib/libmad.so.0.2.1
b7381000-b7382000 rw-p 00015000 08:02 4334103 /usr/lib/libmad.so.0.2.1
b7382000-b73d0000 r-xp 00000000 08:02 4331056 /usr/lib/i386-linux-gnu/libFLAC.so.8.2.0
b73d0000-b73d1000 r--p 0004d000 08:02 4331056 /usr/lib/i386-linux-gnu/libFLAC.so.8.2.0
b73d1000-b73d2000 rw-p 0004e000 08:02 4331056 /usr/lib/i386-linux-gnu/libFLAC.so.8.2.0
b73d2000-b73d3000 rw-p 00000000 00:00 0
b73d3000-b73fd000 r-xp 00000000 08:02 4328031 /usr/lib/i386-linux-gnu/libvorbis.so.0.4.5
b73fd000-b73fe000 r--p 00029000 08:02 4328031 /usr/lib/i386-linux-gnu/libvorbis.so.0.4.5
b73fe000-b73ff000 rw-p 0002a000 08:02 4328031 /usr/lib/i386-linux-gnu/libvorbis.so.0.4.5
b73ff000-b7407000 r-xp 00000000 08:02 4328022 /usr/lib/i386-linux-gnu/libvorbisfile.so.3.3.4
You may want to try this easy step. Pad the stack at both ends with buffers and then examine the contents of the overwritten buffers. Often, examing the contents of the buffers gives a pretty good clue as to where the problem may be.
#include <stdio.h>
#include <string.h>
#define DEBUG 1
/*
* If stack is getting corrupted then this buf should change.
* Looking at the contents of the buf should give a hint at
* what is causing it.
*/
#if DEBUG
#define PAD_SIZE 1024
#define PAD_CHAR 0xE5
static void
check_buf(char *name, char *s)
{
int j, count = 0;
for (j = 0; j < PAD_SIZE; j++) {
if ((unsigned char)*s != PAD_CHAR) {
count++;
}
s++;
}
if (count != 0) {
printf("%s corrupted by %d bytes\n", name, count);
}
}
#endif
/*
* Stack smashing happens when attempting to return from foo.
*/
int
foo(/* some calling args go here */)
{
#if DEBUG
char pad_a[PAD_SIZE];
#endif
/*
* Rest of your ALL auto variables go here.
*/
#if DEBUG
char pad_b[PAD_SIZE];
memset(pad_a, PAD_CHAR, PAD_SIZE);
memset(pad_b, PAD_CHAR, PAD_SIZE);
#endif
/*
* foo does its work and somehow ends up corrupting the
* stack. We normally learn about the problem when the
* function attempts to return.
*/
#if DEBUG
check_buf("foo():pad_a", pad_a);
check_buf("foo():pad_b", pad_b);
#endif
return(1);
}
Let us know how it goes.
Have you used the exp-sgcheck tool for Valgrind or just the memcheck tool? It sounds like sgcheck may do what you want. From the Valgrind docs:
SGCheck and Memcheck are complementary: their capabilities do not overlap. Memcheck
performs bounds checks and use-after-free checks for heap arrays. It also finds uses of
uninitialised values created by heap or stack allocations. But it does not perform bounds
checking for stack or global arrays.
SGCheck, on the other hand, does do bounds checking for stack or global arrays, but it
doesn't do anything else.
There are some caveats about how exactly exp-sgcheck find potential errors (and it is considered experimental) so read the docs carefully before trying it out.
Edit:
Here's another idea to try. If you break on function entry can you determine an address that will be corrupted by the time the function exits? Perhaps by getting the address of a stack variable or something? If so you could set a gdb watch point on that address. gdb will stop the program whenever this memory location gets modified. This can be pretty annoying if it's an address that's modified often but can, in a pinch, function as a poor man's stack guard. Here's a link to the docs.
You don't have to have a special stack guard, you just need to watch something on the stack which you know will be corrupted. For example, given the following program:
void bar(int j) {
int *addr = (&j) - 20;
for(int i = 0; i <= 1000; i++) {
*(addr + i) = 0xDEADBEEF;
}
}
int main() {
bar(10);
return 0;
}
If you break on entry to bar and set watch j then continue you should get a break when i == 20 inside the loop. If j is supposed to be changed inside the function this is obviously pretty annoying. If you have just an address you can watch that by dereferencing it watch *(int*)0x40051f.
You may want to try Address Sanitizer : http://clang.llvm.org/docs/AddressSanitizer.html
It requires to be able to compile your code with clang, but ASAN is very good at finding stack smashing bugs.
I'm getting the familiar free(): invalid pointer error. In trying to debug, I ended up commenting out each free() in my code, one by one, until there were none left and I'm still getting this runtime error. Has anyone else run into a similar issue?
By the way - it's difficult for me to debug this using gdb, because the entire server doesn't actually crash when the error message is printed, just the particular forked process that was handling the single client.
Thank you.
==============================
*** glibc detected *** ./server: free(): invalid pointer: 0x08641a38 ***
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(+0x6b961)[0xefe961]
/lib/i386-linux-gnu/libc.so.6(+0x6d28b)[0xf0028b]
/lib/i386-linux-gnu/libc.so.6(cfree+0x6d)[0xf0341d]
/usr/lib/i386-linux-gnu/libstdc++.so.6(_ZdlPv+0x21)[0x4c74d1]
./server[0x804b499]
./server[0x804b2ad]
./server[0x804aecd]
./server[0x804ad36]
./server[0x804a3a3]
/lib/i386-linux-gnu/libc.so.6(+0x2fa6f)[0xec2a6f]
/lib/i386-linux-gnu/libc.so.6(+0x2facf)[0xec2acf]
./server[0x804966b]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0xea9e37]
./server[0x8049331]
======= Memory map: ========
00338000-00352000 r-xp 00000000 08:01 394236 /lib/i386-linux-gnu/libgcc_s.so.1
00352000-00353000 r--p 00019000 08:01 394236 /lib/i386-linux-gnu/libgcc_s.so.1
00353000-00354000 rw-p 0001a000 08:01 394236 /lib/i386-linux-gnu/libgcc_s.so.1
003c1000-003c2000 r-xp 00000000 00:00 0 [vdso]
0041d000-004fc000 r-xp 00000000 08:01 792946 /usr/lib/i386-linux-gnu/libstdc++.so.6.0.14
004fc000-00500000 r--p 000de000 08:01 792946 /usr/lib/i386-linux-gnu/libstdc++.so.6.0.14
00500000-00501000 rw-p 000e2000 08:01 792946 /usr/lib/i386-linux-gnu/libstdc++.so.6.0.14
00501000-00508000 rw-p 00000000 00:00 0
00664000-00688000 r-xp 00000000 08:01 394245 /lib/i386-linux-gnu/libm-2.13.so
00688000-00689000 r--p 00023000 08:01 394245 /lib/i386-linux-gnu/libm-2.13.so
00689000-0068a000 rw-p 00024000 08:01 394245 /lib/i386-linux-gnu/libm-2.13.so
00793000-007af000 r-xp 00000000 08:01 394195 /lib/i386-linux-gnu/ld-2.13.so
007af000-007b0000 r--p 0001b000 08:01 394195 /lib/i386-linux-gnu/ld-2.13.so
007b0000-007b1000 rw-p 0001c000 08:01 394195 /lib/i386-linux-gnu/ld-2.13.so
00960000-0096a000 r-xp 00000000 08:01 394254 /lib/i386-linux-gnu/libnss_files-2.13.so
0096a000-0096b000 r--p 00009000 08:01 394254 /lib/i386-linux-gnu/libnss_files-2.13.so
0096b000-0096c000 rw-p 0000a000 08:01 394254 /lib/i386-linux-gnu/libnss_files-2.13.so
00e93000-00fed000 r-xp 00000000 08:01 394208 /lib/i386-linux-gnu/libc-2.13.so
00fed000-00fee000 ---p 0015a000 08:01 394208 /lib/i386-linux-gnu/libc-2.13.so
00fee000-00ff0000 r--p 0015a000 08:01 394208 /lib/i386-linux-gnu/libc-2.13.so
00ff0000-00ff1000 rw-p 0015c000 08:01 394208 /lib/i386-linux-gnu/libc-2.13.so
00ff1000-00ff4000 rw-p 00000000 00:00 0
08048000-08056000 r-xp 00000000 08:01 1084793 /home/mwrosen/cpe464/prog2/server
08056000-08057000 r--p 0000d000 08:01 1084793 /home/mwrosen/cpe464/prog2/server
08057000-08058000 rw-p 0000e000 08:01 1084793 /home/mwrosen/cpe464/prog2/server
08641000-08662000 rw-p 00000000 00:00 0 [heap]
b7600000-b7621000 rw-p 00000000 00:00 0
b7621000-b7700000 ---p 00000000 00:00 0
b7718000-b771b000 rw-p 00000000 00:00 0
b7729000-b772c000 rw-p 00000000 00:00 0
bfacf000-bfaf0000 rw-p 00000000 00:00 0 [stack]
If your code trashes a pointer used by some other code, other code may wind up calling free on an invalid pointer. Likely you are accessing some memory you don't own.
There are many ways this can happen, here are two common ones:
1) If you declare an array like int f[7];, the last array element is f[6]. Modifying f[7] can corrupt someone else's memory.
2) If you save a pointer to an object allocated on the stack, that object goes out of scope, and then you modify something through that pointer, you can corrupt someone else's memory.
Try to use valgrind to debug your issue.
If your error persist even with all free removed, it could be because some code is overflowing its memory zone (e.g. a buffer overflow).
I'm tackling a trivial buffer overflow (yes, exploitation; but unrelated to the problem) I'm trying to figure out the fields in the memory map, when GCC's stack protector is enabled. As an illustration:
$ ./overflow
*** stack smashing detected ***: ./overflow terminated
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb7f67da8]
/lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x0)[0xb7f67d60]
./overflow[0x804845c]
[0x41414141]
======= Memory map: ========
08048000-08049000 r-xp 00000000 08:06 3704767 /home/hatred/w0rk/bugz
08049000-0804a000 r--p 00000000 08:06 3704767 /home/hatred/w0rk/bugz
0804a000-0804b000 rw-p 00001000 08:06 3704767 /home/hatred/w0rk/bugz
0804b000-0806c000 rw-p 0804b000 00:00 0 [heap]
b7e5a000-b7e67000 r-xp 00000000 08:06 368705 /lib/libgcc_s.so.1
b7e67000-b7e68000 r--p 0000c000 08:06 368705 /lib/libgcc_s.so.1
b7e68000-b7e69000 rw-p 0000d000 08:06 368705 /lib/libgcc_s.so.1
b7e69000-b7e6a000 rw-p b7e69000 00:00 0
b7e6a000-b7fc6000 r-xp 00000000 08:06 386037 /lib/tls/i686/cmov/libc-2.9.so
b7fc6000-b7fc7000 ---p 0015c000 08:06 386037 /lib/tls/i686/cmov/libc-2.9.so
b7fc7000-b7fc9000 r--p 0015c000 08:06 386037 /lib/tls/i686/cmov/libc-2.9.so
b7fc9000-b7fca000 rw-p 0015e000 08:06 386037 /lib/tls/i686/cmov/libc-2.9.so
b7fca000-b7fcd000 rw-p b7fca000 00:00 0
b7fdf000-b7fe1000 rw-p b7fdf000 00:00 0
b7fe1000-b7fe2000 r-xp b7fe1000 00:00 0 [vdso]
b7fe2000-b7ffe000 r-xp 00000000 08:06 368654 /lib/ld-2.9.so
b7ffe000-b7fff000 r--p 0001b000 08:06 368654 /lib/ld-2.9.so
b7fff000-b8000000 rw-p 0001c000 08:06 368654 /lib/ld-2.9.so
bffeb000-c0000000 rw-p bffeb000 00:00 0 [stack]
Aborted
So, as you can see; There's the backtrace, and then there's the memory map, with 5 fields, and then an optional sixth one which may include a .so.1 (shared libraries?) I'm asking about what these fields are, and what they mean, like the hex fields, and what rw-p means, etc.
I've gone on google and searched but nothing like this comes up.
Thanks.
Check out the man page for the /proc filesystem, it has all the info you need:
/proc/[number]/maps
A file containing the currently mapped memory regions and their access
permissions.
The format is:
address perms offset dev inode pathname
08048000-08056000 r-xp 00000000 03:0c 64593 /usr/sbin/gpm
08056000-08058000 rw-p 0000d000 03:0c 64593 /usr/sbin/gpm
08058000-0805b000 rwxp 00000000 00:00 0
40000000-40013000 r-xp 00000000 03:0c 4165 /lib/ld-2.2.4.so
40013000-40015000 rw-p 00012000 03:0c 4165 /lib/ld-2.2.4.so
4001f000-40135000 r-xp 00000000 03:0c 45494 /lib/libc-2.2.4.so
40135000-4013e000 rw-p 00115000 03:0c 45494 /lib/libc-2.2.4.so
4013e000-40142000 rw-p 00000000 00:00 0
bffff000-c0000000 rwxp 00000000 00:00 0
where address is the address space in the process that it occupies, perms
is a set of permissions:
r = read
w = write
x = execute
s = shared
p = private (copy on write)
offset is the offset into the file/whatever, dev is the device
(major:minor), and inode is the inode
on that device. 0 indicates that no
inode is associated with the memory
region, as the case would be with bss.