Debugger "print" clears memory corruption

Discussion in 'C Programming' started by Gavin Kreuiter, Dec 4, 2003.

  1. I am looking for some advice on how to debug a program when the
    debugger "print" command actually clears the corruption. This is not
    the usual non-initialised memory problem, because the program aborts
    with a SIGBUS inside the debugger as well. But when I use the print
    command inside the debugger, the program completes normally.

    I am using gdb on a linux system. The offending C code is:

    memcpy(new_entry, &newloc, IRECPTRLEN);

    I display these values just before the memcpy:

    printf("Calling memcpy(%p, %p, %d)\n", new_entry, &newloc,
    IRECPTRLEN);

    .... which works. When run straight from gdb (snipped a bit):

    $ gdb xwif
    (gdb) b src/c_library.c:598
    Breakpoint 1 at 0x804bca3: file src/c_library.c, line 598.
    (gdb) run
    Starting program: /home/dev/bin/xwif -p
    Calling memcpy(0x4001f000, 0xbffff04c, 4)

    Breakpoint 1, c$keyed_write (p=0x80520a0, record=0x80658a0 "\002") at
    src/c_library.c:598
    598 memcpy(new_entry, &newloc, IRECPTRLEN);
    (gdb) s

    Program received signal SIGBUS, Bus error.
    0x4207c46c in memcpy () from /lib/i686/libc.so.6

    But when I use "print" before "step":

    $ gdb xwif
    (gdb) b src/c_library.c:598
    Breakpoint 1 at 0x804bca3: file src/c_library.c, line 598.
    (gdb) r

    Starting program: /home/dev/bin/xwif -p
    Calling memcpy(0x4001f000, 0xbffff04c, 4)

    Breakpoint 1, c$keyed_write (p=0x80520a0, record=0x80658a0 "\002") at
    src/c_library.c:598
    598 memcpy(new_entry, &newloc, IRECPTRLEN);
    (gdb) p new_entry
    $1 = 0x4001f000 ""
    (gdb) s
    599 new_entry += IRECPTRLEN;
    (gdb)

    .... and it completes successfully.

    I *know* that I am corrupting memory somewhere (I am calling mmap). I
    wrote a small program to test the way I am using mmap(), and it works.
    But when I try to include it in a much larger application, it aborts.
    I am not asking you to debug my program, nor for help on mmap()
    (although, if you really want to spend hours stepping through my code,
    I won't object :) But I am requesting help with techniques to debug
    programs exhibiting symptoms like the above.
    Gavin Kreuiter, Dec 4, 2003
    #1
    1. Advertising

  2. Gavin Kreuiter

    Grumble Guest

    Gavin Kreuiter wrote:
    > I am looking for some advice on how to debug a program when the
    > debugger "print" command actually clears the corruption. This is not
    > the usual non-initialised memory problem, because the program aborts
    > with a SIGBUS inside the debugger as well. But when I use the print
    > command inside the debugger, the program completes normally.
    >
    > I am using gdb on a linux system. The offending C code is:
    >
    > memcpy(new_entry, &newloc, IRECPTRLEN);


    How is new_entry declared? It is probably read-only. Did you try to
    dynamically allocate space for it before you call memcpy()?

    Do you know about gcc's -Wwrite-strings and -fwritable-strings?
    Grumble, Dec 4, 2003
    #2
    1. Advertising

  3. Gavin Kreuiter wrote:
    > I am looking for some advice on how to debug a program when the
    > debugger "print" command actually clears the corruption. This is not
    > the usual non-initialised memory problem, because the program aborts
    > with a SIGBUS inside the debugger as well. But when I use the print
    > command inside the debugger, the program completes normally.


    Can't you let the program die then see where it happened? gdb usually
    reports where a program crashed.

    SIGBUS is an indication that you have an alignment issue. Remember that
    you can't simply address an arbitrary memory location as if it were an
    int, or a double, or whatever:

    int main(void)
    {
    char a[sizeof(int)];
    int *p = (int *)a;

    *p = 100; /* Possible alignment error! */

    return 0;
    }

    -Kevin
    --
    My email address is valid, but changes periodically.
    To contact me please use the address from a recent posting.
    Kevin Goodsell, Dec 4, 2003
    #3
  4. Gavin Kreuiter

    Chris Torek Guest

    In article <>
    Gavin Kreuiter <> writes:
    >I am looking for some advice on how to debug a program when the
    >debugger "print" command actually clears the corruption. This is not
    >the usual non-initialised memory problem, because the program aborts
    >with a SIGBUS inside the debugger as well. But when I use the print
    >command inside the debugger, the program completes normally.


    >I am using gdb on a linux system. The offending C code is:
    >memcpy(new_entry, &newloc, IRECPTRLEN);


    [examples snipped]

    I suspect neither answer so far is right, and that the problem is
    something more subtle having to do with whether the page(s) is/are
    allocated at the time memcpy() first touches them. Using the
    debugger's "print" command forces a read access to the address, so
    that the page is in RAM (and may even be r/w) by the time you step
    into memcpy().

    There are any number of ways to find out if this is the case, and
    what else might be going on, but all of them are off-topic save one:
    you can force a write access to the first byte at new_entry via:

    *(unsigned char *)new_entry = *(unsigned char *)&newloc;

    before the memcpy() operation. If the behavior changes, you at least
    have some additional information.

    (A Linux-specific group -- which one is not clear -- would be the
    right place to go for information on what extra debugging information
    is available after a SIGBUS is caught in the debugger, and how to
    trace relevant system activity up to that point.)
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: forget about it http://web.torek.net/torek/index.html
    Reading email is like searching for food in the garbage, thanks to spammers.
    Chris Torek, Dec 5, 2003
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. KenG

    window.open clears parent window

    KenG, Feb 4, 2004, in forum: ASP .Net
    Replies:
    4
    Views:
    7,246
    Mike Hennessy
    Feb 17, 2004
  2. Tim Zych
    Replies:
    2
    Views:
    838
    =?Utf-8?B?VHJldm9yIEJlbmVkaWN0IFI=?=
    Jun 7, 2004
  3. Scott W Gifford
    Replies:
    18
    Views:
    3,295
    Mike Schilling
    Dec 22, 2005
  4. Sune
    Replies:
    14
    Views:
    864
    Chris Thomasson
    Aug 26, 2007
  5. Sune
    Replies:
    5
    Views:
    428
    Darko
    Jul 13, 2007
Loading...

Share This Page