Thread: Debugging help

  1. #1
    Registered User
    Join Date
    Jun 2006
    Posts
    3

    Debugging help

    hi, I am new to C and gnu debugger.

    I need some help to understand how to use my gdb backtrace to remove the segmentation fault in my program.

    Here is the trace:

    #0 0x41897150 in _IO_adjust_column () from /lib/tls/libc.so.6
    #1 0x418974f0 in _flushlbf () from /lib/tls/libc.so.6
    #2 0x4185fc34 in exit () from /lib/tls/libc.so.6
    #3 0x41849e48 in __libc_start_main () from /lib/tls/libc.so.6
    #4 0x080484c1 in _start () at ../sysdeps/i386/elf/start.S:119

    This same program was working earlier without any problems when I was using floats everywhere. Now that I converted to doubles I have a segmentation fault.

    Please help me out.. Thanks.

    Ankit.

  2. #2
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    Well if you used dynamic memory, I would first check that you changed your sizeof(float) into sizeof(double) when you worked out the size to allocate.

    Also, try using either valgrind or electric fence.


    Post your code.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  3. #3
    Registered User
    Join Date
    Jun 2006
    Posts
    3
    code is long around 1000 lines and quite dirty (I really am a newbie). I have already replaced the sizeof(float). Also what I am worried about is why doesn't the gdb backtrace give any line numbers about the errors in my file.

    In case you'd still like to see the code, i'll post it.

    Thanks..

  4. #4
    Registered User
    Join Date
    Jun 2006
    Posts
    3
    Also note that my output is still correct. Only the program is not exitting cleanly, it ends in a segmentation fault.

    Ankit

  5. #5
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    Well the segfault occurs where the problem is detected, which is almost certainly not where the problem occurred.

    Here's some example debug strategies
    Code:
    #include <stdlib.h>
    #include <stdio.h>
    
    int main(){
      int *mem = malloc ( 5 * sizeof *mem );
      int i;
      for ( i = 0 ; i <= 5 ; i++ ) {
        mem[i] = i; /* overrun in last iteration */
      }
      free( mem );
      return 0;
    }
    
    
    
    $ gcc -g foo.c
    $ ./a.out
    *** glibc detected *** ./a.out: free(): invalid next size (fast): 0x08091008 ***
    ======= Backtrace: =========
    /lib/libc.so.6[0x5b4424]
    /lib/libc.so.6(__libc_free+0x77)[0x5b495f]
    ./a.out[0x804840b]
    /lib/libc.so.6(__libc_start_main+0xc6)[0x565de6]
    ./a.out[0x804832d]
    ======= Memory map: ========
    0052f000-00549000 r-xp 00000000 fd:00 5342221    /lib/ld-2.3.5.so
    00549000-0054a000 r-xp 00019000 fd:00 5342221    /lib/ld-2.3.5.so
    0054a000-0054b000 rwxp 0001a000 fd:00 5342221    /lib/ld-2.3.5.so
    00551000-00675000 r-xp 00000000 fd:00 5342973    /lib/libc-2.3.5.so
    00675000-00677000 r-xp 00124000 fd:00 5342973    /lib/libc-2.3.5.so
    00677000-00679000 rwxp 00126000 fd:00 5342973    /lib/libc-2.3.5.so
    00679000-0067b000 rwxp 00679000 00:00 0
    008ac000-008b5000 r-xp 00000000 fd:00 5342977    /lib/libgcc_s-4.0.0-20050520.so.1
    008b5000-008b6000 rwxp 00009000 fd:00 5342977    /lib/libgcc_s-4.0.0-20050520.so.1
    00eca000-00ecb000 r-xp 00eca000 00:00 0
    08048000-08049000 r-xp 00000000 fd:00 7274627    /home/me/a.out
    08049000-0804a000 rw-p 00000000 fd:00 7274627    /home/me/a.out
    08091000-080b2000 rw-p 08091000 00:00 0          [heap]
    b7d00000-b7d21000 rw-p b7d00000 00:00 0
    b7d21000-b7e00000 ---p b7d21000 00:00 0
    b7eeb000-b7eec000 rw-p b7eeb000 00:00 0
    b7f0f000-b7f10000 rw-p b7f0f000 00:00 0
    bfefb000-bff10000 rw-p bfefb000 00:00 0          [stack]
    Aborted
    
    
    
    $ valgrind a.out
    ==13495== Memcheck, a memory error detector for x86-linux.
    ==13495== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
    ==13495== Using valgrind-2.4.0, a program supervision framework for x86-linux.
    ==13495== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
    ==13495== For more details, rerun with: -v
    ==13495==
    ==13495== Invalid write of size 4
    ==13495==    at 0x80483F3: main (foo.c:8)
    ==13495==  Address 0x1B93303C is 0 bytes after a block of size 20 alloc'd
    ==13495==    at 0x1B909222: malloc (vg_replace_malloc.c:130)
    ==13495==    by 0x80483D5: main (foo.c:5)
    ==13495==
    ==13495== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 13 from 1)
    ==13495== malloc/free: in use at exit: 0 bytes in 0 blocks.
    ==13495== malloc/free: 1 allocs, 1 frees, 20 bytes allocated.
    ==13495== For counts of detected errors, rerun with: -v
    ==13495== No malloc'd blocks -- no leaks are possible.
    
    
    
    $ gcc -g foo.c -lefence
    $ gdb a.out
    GNU gdb Red Hat Linux (6.3.0.0-1.21rh)
    Copyright 2004 Free Software Foundation, Inc.
    GDB is free software, covered by the GNU General Public License, and you are
    welcome to change it and/or distribute copies of it under certain conditions.
    Type "show copying" to see the conditions.
    There is absolutely no warranty for GDB.  Type "show warranty" for details.
    This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".
    
    (gdb) run
    Starting program: /home/me/a.out
    Reading symbols from shared object read from target memory...done.
    Loaded system supplied DSO at 0x49e000
    
      Electric Fence 2.2.0 Copyright (C) 1987-1999 Bruce Perens <[email protected]>
    
    Program received signal SIGSEGV, Segmentation fault.
    0x080484b3 in main () at foo.c:8
    8           mem[i] = i; /* overrun in last iteration */
    (gdb) print i
    $1 = 5
    (gdb) quit
    The program is running.  Exit anyway? (y or n) y
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Dev-C++: Problems with Breakpoint Debugging
    By Thileepan_Bala in forum C Programming
    Replies: 1
    Last Post: 01-17-2008, 10:48 AM
  2. Problem in debugging in Eclipse
    By Bargi in forum Linux Programming
    Replies: 1
    Last Post: 08-21-2007, 09:53 AM
  3. Debugging Dev C++
    By tuurb046 in forum Tech Board
    Replies: 10
    Last Post: 08-16-2007, 12:51 PM
  4. Debugging book recommendation
    By dagans in forum Projects and Job Recruitment
    Replies: 1
    Last Post: 09-13-2005, 07:35 PM
  5. debugging directx apps
    By confuted in forum C++ Programming
    Replies: 1
    Last Post: 08-16-2003, 08:56 AM