How to debug?

Littlefield, Tyler tyler at tysdomain.com
Mon Jan 30 13:41:03 EST 2012


On 1/27/2012 3:51 PM, Jalil Karimov <jukarimov at 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 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 ?? ()
>
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 at 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.




More information about the Kernelnewbies mailing list