As I learn C, I decided to write a small dictionary program, for my linux box. Unfortunatly, I'm unable to proceed because of that weird bug which I can't debug (no source of crash). Any help is appreciated. strace: read(3, "\270) file box\n 3) \321\200\320\260\320\267\320\263. \320\277\321\200\320\265"..., 4096) = 4096 read(3, "mixture of vodka and beer\n", 4096) = 26 read(3, "", 4096) = 0 close(3) = 0 munmap(0xb7860000, 4096) = 0 write(4, "\320\275\320\276-\320\266\321\221\320\273\321\202\321\213\320\271@11618255\n\321\217\320\270\321"..., 3875) = 3875 close(4) = 0 munmap(0xb785f000, 4096) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ gdb: Program received signal SIGSEGV, Segmentation fault. 0x80d15d70 in ?? () valgrind: ==11809== Memcheck, a memory error detector ==11809== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==11809== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info ==11809== Command: ./dic -u ==11809== Parent PID: 1662 ==11809== ==11809== Jump to the invalid address stated on the next line ==11809== at 0x80D15D70: ??? ==11809== Address 0x80d15d70 is not stack'd, malloc'd or (recently) free'd ==11809== ==11809== ==11809== Process terminating with default action of signal 11 (SIGSEGV) ==11809== Access not within mapped region at address 0x80D15D70 ==11809== at 0x80D15D70: ??? ==11809== If you believe this happened as a result of a stack ==11809== overflow in your program's main thread (unlikely but ==11809== possible), you can try to increase the size of the ==11809== main thread stack using the --main-stacksize= flag. ==11809== The main thread stack size used in this run was 8388608. ==11809== ==11809== HEAP SUMMARY: ==11809== in use at exit: 70 bytes in 2 blocks ==11809== total heap usage: 426,629 allocs, 426,627 frees, 224,953,822 bytes allocated ==11809== ==11809== LEAK SUMMARY: ==11809== definitely lost: 70 bytes in 2 blocks ==11809== indirectly lost: 0 bytes in 0 blocks ==11809== possibly lost: 0 bytes in 0 blocks ==11809== still reachable: 0 bytes in 0 blocks ==11809== suppressed: 0 bytes in 0 blocks ==11809== Rerun with --leak-check=full to see details of leaked memory ==11809== ==11809== For counts of detected and suppressed errors, rerun with: -v ==11809== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 20 from 7)
Hi :) On Sat, Jan 28, 2012 at 05:51, Jalil Karimov <jukarimov@gmail.com> <jukarimov@gmail.com> wrote:
As I learn C, I decided to write a small dictionary program, for my linux box. Unfortunatly, I'm unable to proceed because of that weird bug which I can't debug (no source of crash). Any help is appreciated.
Are you aware your question is not kernel related? :) but anyway...
munmap(0xb7860000, 4096) = 0 write(4, "\320\275\320\276-\320\266\321\221\320\273\321\202\321\213\320\271@11618255\n\321\217\320\270\321"..., 3875) = 3875 close(4) = 0 munmap(0xb785f000, 4096) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++
looks like the bug triggered by releasing certain portion of heap....sounds like double free()? could you recompile your application using -g (a gcc parameter) and then run it again under gdb? hopefully you get better stack strace along with complete symbol names...
==11809== Jump to the invalid address stated on the next line ==11809== at 0x80D15D70: ??? ==11809== Address 0x80d15d70 is not stack'd, malloc'd or (recently) free'd ==11809== ==11809== ==11809== Process terminating with default action of signal 11 (SIGSEGV) ==11809== Access not within mapped region at address 0x80D15D70
or.... you access something that haven't been initialized or malloc()-ed properly. Now I leave it to you to re-audit your source code :) hope it helps.. -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
Oops, sorry for spam, I found it, there was char[80] But in dictionary there's a string longer than that, fixed now :D Cheers, Jalil On Sat, 28 Jan 2012, Mulyadi Santosa wrote:
Hi :)
On Sat, Jan 28, 2012 at 05:51, Jalil Karimov <jukarimov@gmail.com> <jukarimov@gmail.com> wrote:
As I learn C, I decided to write a small dictionary program, for my linux box. Unfortunatly, I'm unable to proceed because of that weird bug which I can't debug (no source of crash). Any help is appreciated.
Are you aware your question is not kernel related? :) but anyway...
munmap(0xb7860000, 4096) = 0 write(4, "\320\275\320\276-\320\266\321\221\320\273\321\202\321\213\320\271@11618255\n\321\217\320\270\321"..., 3875) = 3875 close(4) = 0 munmap(0xb785f000, 4096) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++
looks like the bug triggered by releasing certain portion of heap....sounds like double free()?
could you recompile your application using -g (a gcc parameter) and then run it again under gdb? hopefully you get better stack strace along with complete symbol names...
==11809== Jump to the invalid address stated on the next line ==11809== at 0x80D15D70: ??? ==11809== Address 0x80d15d70 is not stack'd, malloc'd or (recently) free'd ==11809== ==11809== ==11809== Process terminating with default action of signal 11 (SIGSEGV) ==11809== Access not within mapped region at address 0x80D15D70
or.... you access something that haven't been initialized or malloc()-ed properly. Now I leave it to you to re-audit your source code :)
hope it helps..
-- regards,
Mulyadi Santosa Freelance Linux trainer and consultant
blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
On Sat, Jan 28, 2012 at 08:06, Jalil Karimov <jukarimov@gmail.com> <jukarimov@gmail.com> wrote:
Oops, sorry for spam, I found it, there was char[80] But in dictionary there's a string longer than that, fixed now :D
no problem :) classic bug :) -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
On 1/27/2012 3:51 PM, Jalil Karimov <jukarimov@gmail.com> wrote:
As I learn C, I decided to write a small dictionary program, for my linux box. Unfortunatly, I'm unable to proceed because of that weird bug which I can't debug (no source of crash). Any help is appreciated.
this would be better suited for another list...
strace:
Strace for debugging? It has it's uses, but you need to use a -debugger- to debug.
read(3, "\270) file box\n 3) \321\200\320\260\320\267\320\263. \320\277\321\200\320\265"..., 4096) = 4096 read(3, "mixture of vodka and beer\n", 4096) = 26 read(3, "", 4096) = 0 close(3) = 0 munmap(0xb7860000, 4096) = 0 write(4, "\320\275\320\276-\320\266\321\221\320\273\321\202\321\213\320\271@11618255\n\321\217\320\270\321"..., 3875) = 3875 close(4) = 0 munmap(0xb785f000, 4096) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++
gdb: Program received signal SIGSEGV, Segmentation fault. 0x80d15d70 in ?? ()
I recommend you compile with debugging symbols. gcc/g++ -GGdb or just -G.
valgrind: ==11809== Memcheck, a memory error detector ==11809== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==11809== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info ==11809== Command: ./dic -u ==11809== Parent PID: 1662 ==11809== ==11809== Jump to the invalid address stated on the next line ==11809== at 0x80D15D70: ??? ==11809== Address 0x80d15d70 is not stack'd, malloc'd or (recently) free'd ==11809== ==11809== ==11809== Process terminating with default action of signal 11 (SIGSEGV) ==11809== Access not within mapped region at address 0x80D15D70 ==11809== at 0x80D15D70: ??? ==11809== If you believe this happened as a result of a stack ==11809== overflow in your program's main thread (unlikely but ==11809== possible), you can try to increase the size of the ==11809== main thread stack using the --main-stacksize= flag. ==11809== The main thread stack size used in this run was 8388608. ==11809== ==11809== HEAP SUMMARY: ==11809== in use at exit: 70 bytes in 2 blocks ==11809== total heap usage: 426,629 allocs, 426,627 frees, 224,953,822 bytes allocated ==11809== ==11809== LEAK SUMMARY: ==11809== definitely lost: 70 bytes in 2 blocks ==11809== indirectly lost: 0 bytes in 0 blocks ==11809== possibly lost: 0 bytes in 0 blocks ==11809== still reachable: 0 bytes in 0 blocks ==11809== suppressed: 0 bytes in 0 blocks ==11809== Rerun with --leak-check=full to see details of leaked memory ==11809== ==11809== For counts of detected and suppressed errors, rerun with: -v ==11809== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 20 from 7)
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Take care, Ty Web: http://tds-solutions.net The Aspen project: a light-weight barebones mud engine http://code.google.com/p/aspenmud Sent from my toaster.
participants (3)
-
Jalil Karimov <jukarimov＠gmail.com> -
Littlefield, Tyler -
Mulyadi Santosa