Reverse memory lookup

[ewmayer]

In C/C++, it's trivial to map from a variable name (either scalar or pointer+offset) to the memory location. Is there a way (or tool) allowing one to find which variable / function / allocated-memory-block a given address maps to? I am trying to localize a valgrind (specifically the DRD thread-analysis tool) error, and valgrind is only giving the address in question, no associated name:

Conflicting store by thread 3 at 0x10041fc00 size 4

[rogue]

Originally Posted by ewmayer

In C/C++, it's trivial to map from a variable name (either scalar or pointer+offset) to the memory location. Is there a way (or tool) allowing one to find which variable / function / allocated-memory-block a given address maps to? I am trying to localize a valgrind (specifically the DRD thread-analysis tool) error, and valgrind is only giving the address in question, no associated name:

Conflicting store by thread 3 at 0x10041fc00 size 4

Did you compile with -g and no optimizations?

[ewmayer]

Originally Posted by rogue

Did you compile with -g and no optimizations?

Yes - I used -Wall -g3 -ggdb .

[ldesnogu]

Originally Posted by ewmayer

In C/C++, it's trivial to map from a variable name (either scalar or pointer+offset) to the memory location. Is there a way (or tool) allowing one to find which variable / function / allocated-memory-block a given address maps to? I am trying to localize a valgrind (specifically the DRD thread-analysis tool) error, and valgrind is only giving the address in question, no associated name:

Conflicting store by thread 3 at 0x10041fc00 size 4

For what's it's worth, I use the nm command (with -v option to sort by value) for variables and functions. Of course that won't help for dynamically allocated memory.

[ewmayer]

Originally Posted by ldesnogu

For what's it's worth, I use the nm command (with -v option to sort by value) for variables and functions. Of course that won't help for dynamically allocated memory.

Thanks, Laurent - that is worth quite a lot, as it's just what I needed: I had already added debug-printing of dynamically allocated memory blocks, and saw that the addresses flagged by valgrind/DRD were falling outside those address ranges, so I figured it was local storage of some kind. With the binutils "nm -v" dump, I see immediately that I had not been sufficiently careful to get rid of all remaining static variables (except for those of the read-only variety) from my || implementation of the code in question. Fixing that gets rid of most of the "Conflicting store" error messages ... ah, looks like I also need to add a bit of mutex magic to some routines, to make sure the local-array storage (which I use for SSE register-data constants and register spill management here) gets initialized by the master thread before any of the other threads try to read it.

DRD looks like it's going to be a very handy tool to have around.

[ewmayer]

OK, another multithreaded-code-debug issue: I am getting a divide-by-zero exception in a newly-put-together pthreaded worker-function routine. My source code has no explicit DIVs, so it appears the DIV is resulting from thread-management code. Valgrind DRD indicates the following may be the cause:

==1595== Use of uninitialised value of size 8
==1595== at 0x10017D633: cy_process_chunk (in ./Mlucas_sse2)
==1595== by 0x10025A1C2: worker_thr_routine (in ./Mlucas_sse2)
==1595== by 0x100373FD5: _pthread_start (in /usr/lib/libSystem.B.dylib)
==1595== by 0x100373E88: thread_start (in /usr/lib/libSystem.B.dylib)

In trying to localize the error, I first looked for the first of the above addresses in the output of "nm -v" run on the binary - no match. Then I re-ran under gdb (note the binary is compiled unoptimized with -g), which catches the exception, and reveals the DIV (boldfaced) within a disassembly dump:

(gdb) disass
Dump of assembler code for function worker_thr_routine:
0x0000000100259fe0 <worker_thr_routine+0>:    push   %rbp
0x0000000100259fe1 <worker_thr_routine+1>:    mov    %rsp,%rbp
0x0000000100259fe4 <worker_thr_routine+4>:    push   %r15
0x0000000100259fe6 <worker_thr_routine+6>:    push   %r14
0x0000000100259fe8 <worker_thr_routine+8>:    push   %r13
0x0000000100259fea <worker_thr_routine+10>:    push   %r12
0x0000000100259fec <worker_thr_routine+12>:    push   %rbx
0x0000000100259fed <worker_thr_routine+13>:    sub    $0x58,%rsp
0x0000000100259ff1 <worker_thr_routine+17>:    mov    %rdi,-0x58(%rbp)
0x0000000100259ff5 <worker_thr_routine+21>:    mov    (%rdi),%r15d
0x0000000100259ff8 <worker_thr_routine+24>:    mov    0x8(%rdi),%rbx
0x0000000100259ffc <worker_thr_routine+28>:    callq  0x10029f3fc <dyld_stub_mach_thread_self>
0x000000010025a001 <worker_thr_routine+33>:    mov    %eax,%r12d
0x000000010025a004 <worker_thr_routine+36>:    movl   $0x0,-0x40(%rbp)
0x000000010025a00b <worker_thr_routine+43>:    lea    -0x40(%rbp),%rdx
0x000000010025a00f <worker_thr_routine+47>:    mov    $0x1,%ecx
0x000000010025a014 <worker_thr_routine+52>:    mov    $0x1,%esi
0x000000010025a019 <worker_thr_routine+57>:    mov    %eax,%edi
0x000000010025a01b <worker_thr_routine+59>:    callq  0x10029f4f2 <dyld_stub_thread_policy_set>
0x000000010025a020 <worker_thr_routine+64>:    test   %eax,%eax
0x000000010025a022 <worker_thr_routine+66>:    jne    0x10025a445 <worker_thr_routine+1125>
0x000000010025a028 <worker_thr_routine+72>:    movzwl 0x4a(%rbx),%eax
0x000000010025a02c <worker_thr_routine+76>:    mov    %r15d,%edx
0x000000010025a02f <worker_thr_routine+79>:    mov    %eax,%ecx
0x000000010025a031 <worker_thr_routine+81>:    mov    %r15d,%eax
0x000000010025a034 <worker_thr_routine+84>:    sar    $0x1f,%edx
0x000000010025a037 <worker_thr_routine+87>:    idiv   %ecx
0x000000010025a039 <worker_thr_routine+89>:    mov    %edx,-0x50(%rbp)
0x000000010025a03c <worker_thr_routine+92>:    lea    -0x50(%rbp),%rdx
0x000000010025a040 <worker_thr_routine+96>:    mov    $0x1,%ecx
0x000000010025a045 <worker_thr_routine+101>:    mov    $0x1,%esi
...

I need to figure out which variable or array element is the argument to the IDIV which is causing the problem. Suggestions welcome.

[ewmayer]

Found the problem: By playing with various things - adding some sanity spot-checks of key parts of thread-local-memory, testing things with various #threads starting with the "this had better work" value of 1, etc, I determined that some of the bookkeeping I added for the SSE2 register-spill/fill portion of the thread-local memory store was getting corrupted ... apparently the div-by-zero in the pthread-lib thread management code was a side effect of the resulting memory corruption.

Thanks to jasonp for some comparative threadpool-code checking - that didn't tell e what the problem was, but gave some clues as to what it likely was not.