-
-
Notifications
You must be signed in to change notification settings - Fork 728
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Display tcache for all threads, not just main thread #634
Comments
I have working-but-messy code sitting over in b340eb7, with one significant problem. To determine the exact layout of So if you're using Fedora (as I am), the change in Options:
|
Yeah, that's some hairiness for sure. I don't like version hacks and such to exist in GEF, but maybe it makes sense here. The glibc heap makes sense most of all to have these version hacks (do we even work with pre-tcache versions?). Maybe we should add these hacks, it would definitely be helpful for many. Maybe these checks should exist as an optional cc @hugsy |
Sleeping on problems brings new insights! It occurred to me that the tcache is itself a glibc chunk (source), so we can use the size of that chunk to tell us how large the tcache struct is. No checking I'll continue working on cleaning up the code (and deleting now unneeded methods like |
Is your feature request related to a problem? Please describe.
Currently, gef only correctly displays tcachebins for the main thread. (See screenshot at the bottom for example.)
Describe the solution you'd like
I'd like to upgrade gef to correctly display all tcachebins. I'd like to do this myself, but I think this will actually take a little bit of redesign, so I wanted to get some feedback before starting.
gef lists tcachebins as if they are associated with arenas - they are not. You can't get the address of a tcache from the information an arena gives you because each tcache is allocated (source). (The main thread's tcache is an exception. Since it's allocated early, we can guarantee that it will be at the same offset from the main arena. This is how gef finds tcaches currently.)
So the tcache command should be redesigned to be independent of arenas.
Potential implementation
It's relatively easy to get the address of each tcache using native gdb commands, though they aren't printed in an easy-to-parse output.
thread apply all p (void *) tcache
It gets a little bit more difficult inside gef.
gdb.inferiors.threads
will get you all the thread objects, butgdb.InferiorThread
doesn't expose any tcache information. The dumb way is to switch between each thread and get the tcache for each one. Semi-plausible code might look like:Interface
It seems reasonable to allow the user to 1) allow the user to print all the tcachebins, and 2) print only the tcache bin for a specific thread. The interesting question is what to do when the user types
heap bins
. Should we display all the tcachebins? Only the tcachebins for the current thread? None of the tcachebins? My initial preference would be to display the tcachebins for the current thread, but change the title fromtcachebins for arena 0xdeadbeef
totcachebins for thread 1
.Additional context
Example of gef not displaying tcachebins correctly using
heap-non-main-arena.out
. I can find the thread's tcache manually, but gef won't display it.The text was updated successfully, but these errors were encountered: