By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,750 Members | 1,221 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,750 IT Pros & Developers. It's quick & easy.

Debugger "print" clears memory corruption

P: n/a
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.
Nov 13 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
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?

Nov 13 '05 #2

P: n/a
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.

Nov 13 '05 #3

P: n/a
In article <ae**************************@posting.google.com >
Gavin Kreuiter <kr******@netscape.net> 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 (4039.22'N, 11150.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.
Nov 13 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.