This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug python/19288] need a way to see if an address is covered by some existing object


https://sourceware.org/bugzilla/show_bug.cgi?id=19288

Andrew Dinn <adinn at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adinn at redhat dot com

--- Comment #6 from Andrew Dinn <adinn at redhat dot com> ---
this is also an issue for the OpenJDK unwinder and it is probably also the case
that running the python unwinder after all the other unwinders have had a go
would resolve the problem.

I also observed gdb crashes and also Python stack overflows in my initial
implementation.

The stack overflow only happens for some unwind attempts, in particular it
appears when the base frame for the pending frame has level -1. when the
unwinder calls back in to certain gdb routines gdb tries to re-establish the
frame stack. so the unwinder gets called again and makes the same callout and
so on.

The crash seems to be able to happen with or without the recursion and again
only happens for certain starting frames and only when the unwinder calls back
in to certain gdb routines. the problem is that in these circumstances the gdb
routine decides to call method reinit_frame_stack. even if the recursion is
avoided this still ends up freeing the block that contains the base frame which
backs the pending_frame passed to the unwinder's __call__ method i.e. the code
which invoked __call__ is left with a dangling pointer. by the time the the
unwinder returns the block has usually been reallocated and scribbled over.
invariably, gdb asserts on return from __call__.

I bypassed the recursion problem by detecting recursive calls to my unwinder's
__call__ method (using an association list keyed by thread to detect an
outstanding call) and backing out of any call which results in recursion to
return None. This appears to bypass the check of the invalid base frame and
leaves the problematic frames for some other sniffer to deal with.

I bypassed cases where a crash was caused without recursive entry simply by
tweaking my python code until it went away.

This is clearly a bit inadequate, especially the latter 'fix' which is really a
time-bomb. It would be better if the gdb python API could i) detect recursive
entry into an unwinder and ii)  detect that reinit_frame_stack (and, indeed,
any other code which might inadvertently leave a dangling pointer) has been
called below a frame sniffer. it should really throw an exception so the
sniffer can back out rather than leaving potential for a gdb crash.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]