How to debug?
Jalil Karimov <jukarimov@gmail.com>
jukarimov at gmail.com
Fri Jan 27 17:51:27 EST 2012
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 at 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)
More information about the Kernelnewbies
mailing list