1

I'm trying to debug a unit test; on the 5943rd call to memcpy_c, it should panic but doesn't. To debug this, I'm using gdb's tracepoint mechanism to record data from all of these calls.

Here's my debugging session:

Setting up target & tracing

(gdb) target remote :53268
Remote debugging using :53268
0x00000000004068de in _start ()
(gdb) trace memcpy_c
Tracepoint 1 at 0x402718: file memory.c, line 49.
(gdb) actions
Enter actions for tracepoint 1, one per line.
End with a line saying just "end".
>collect dst, bufsize, src, count
>end
(gdb) break lsc_exit
Breakpoint 2 at 0x406a00

Running the program

(gdb) tstart
(gdb) continue
Continuing.

Breakpoint 2, 0x0000000000406a00 in lsc_exit ()
(gdb) tstop

Analyzing the trace

I can get data for snapshot 5900:

(gdb) tfind 5900
Found trace frame 5900, tracepoint 1
#0  memcpy_c (dst=0x7fffffffe539, dst@entry=<error reading variable: PC not available>, bufsize=785, bufsize@entry=<error reading variable: PC not available>, src=0x7fffffffe4c8, 
    src@entry=<error reading variable: PC not available>, count=5, count@entry=<error reading variable: PC not available>) at memory.c:49
49      if (dst == NULL) {
(gdb) tdump
Data collected at tracepoint 1, trace frame 5900:
dst = (void * restrict) 0x7fffffffe539
bufsize = 785
src = (const void * restrict) 0x7fffffffe4c8
count = 5

I can't get data for snapshot 5943 (the last snapshot, which I'm trying to debug):

(gdb) tfind 5943
Found trace frame 5943, tracepoint 1
#0  memcpy_c (dst=<unavailable>, bufsize=<unavailable>, src=<unavailable>, count=<unavailable>) at memory.c:49
49      if (dst == NULL) {
(gdb) tdump
Data collected at tracepoint 1, trace frame 5943:
dst = <unavailable>
bufsize = <unavailable>
src = <unavailable>
count = <unavailable>

What could be causing the parameters to show up as <unavailable>?

For reference, here is memcpy_c:

void *memcpy_c(void *restrict dst, ulen bufsize, const void *restrict src, ulen count) {
    if (dst == NULL) {
            panic_static("memcpy_c destination pointer is NULL");
    }
    if (src == NULL) {
            panic_static("memcpy_c source pointer is NULL");
    }
    if (count > bufsize) {
            panic_static("memcpy_c caught overflow");
    }
    if (dst + count >= src && dst < src + count) {
            panic_static("memcpy_c attempted to use overlapping regions");
    }
    return memcpy(dst, src, count);
}
Cel Skeggs
  • 1,827
  • 21
  • 38
  • Optimizations can cause this, try compiling your code with -O3 flag and see if this changes – Ishay Peled Jun 07 '15 at 06:32
  • @IshayPeled Why would *turning on* optimizations help? That would seem like it would make it worse rather than better, if anything. It's currently using default optimizations. Also, wouldn't the optimizations cause this to occur every time, not just in specific runthroughs of the method? – Cel Skeggs Jun 07 '15 at 17:05
  • Of course, I meant turn the off!!! -O0. I have no idea why I wrote O3... I encountered this same exact issue when working on some Android code – Ishay Peled Jun 07 '15 at 17:30

0 Answers0