views:

226

answers:

3

I have a pointer in GDB, how can I find out where it was first allocated on the heap?

In WinDBG, this can be done by !heap -p -a <0x12345678> after turning on gflags /i <*exe> +ust

Since Valgrind can tell me where the memory is allocated (when it detects some leaks), I guess this is also possible?

(This is NOT about watchpoint. This is given the situation where I randomly break into the In GDB, application, look at a pointer and want to know "who created this piece of memory"?)


Using reverse debugging in GDB is a very novel way and probably the correct way to solve this problem. I encountered some problem with that approach with GDB 7.1 -- the latest stable version. Reverse debugging is a rather new feature in GDB so I needed to check out HEAD (7.2) to fix it.

It probably says something about the matureness of the GDB approach but I think it should definitely be used when it's more mature. (Awesome feature!)

+1  A: 

Valgrind hijacks memory management calls, that's how heap checkers work. There's no facility in GDB itself to tell you where given address was returned by malloc(3). I suggest looking into mtrace and glibc allocation debugging.

Nikolai N Fetissov
Thanks! Both your approach and ks1322's seem valid. It's insightful to know about mtrace and glib allocation debugging. On the other hand, I feel ks1332's approach is more clever and probably closer to GDB (thus the question title). I'll experiment with both and see which one is better in practice before choosing a correct answer.
kizzx2
+2  A: 

Maby reverse debugging will help here. Try to set watchpoint on memory address and reverse-continue until memory written.

(gdb) watch *0x12345678
(gdb) reverse-continue
ks1322
Thanks! Both your approach and Nikolai's seem valid. Your approach is more clever and probably closer to GDB (thus the question title). On the other hand it's insightful to know about mtrace and glib allocation debugging. I'll experiment with both and see which one is better in practice before choosing a correct answer.
kizzx2
Yes, this is fun, but I don't think it's practical other than for very small programs (never even mind multithreading).
Nikolai N Fetissov
@Nikolai: it seems to be true. While reverse-debugging is really exciting from the technical point of view, it probably isn't mature enough in many cases. One showstopper is that `record` it will *not* run in a Hello World program, because it refuses to record any IO (TTY, filesystem, etc.). That alone makes it impractical to use in any real life situation. I'm not sure if that's the intended behavior.
kizzx2
Yes, it seems reverse-debugging needs to be improved to be used in practice.
ks1322
+1  A: 

record DOES run on a Hello World program. Heck I use record to debug gdb itself!

Michael Snyder
Thanks for reminding! I was obviously ignorant when I tried -- it said "operation unsupported or something." I think it might be related to 32bit 64bit problems. I tried again at a purely 32 bit Ubuntu and it worked like a charm! Any guidance on why it might not work on Arch x86_64? (I suspect it might be related to 64 bit version of glibc or something, I dunno :P)
kizzx2
record/replay sometimes spits out some warnings, but that doesn't necessarily mean that it isn't working. It should also work for x86_64, but i386 support is more mature.
Michael Snyder
@Michael -- I looked into the issue. This particular problem was because my libc was compiled to contain some MMX instructions which GDB 7.1 didn't support. I checked out HEAD (7.2 at the time of writing) and it worked.
kizzx2