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

["adinn at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

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

--- Comment #19 from Andrew Dinn <adinn at redhat dot com> ---
(In reply to Tom Tromey from comment #16)
> (In reply to Pedro Alves from comment #15)
> 
> > But wouldn't it be more robust to check whether it's an address you know you 
> > can unwind (by consulting whatever tables the JIT uses internally), instead
> > of 
> > checking whether the program stopped at an address you can't unwind?
> 
> For sure, but we ran into other problems when trying to do this:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1259867
> (I couldn't reproduce this in the same way to debug it, instead I
> got an infinite recursion in gdb -- basically doing anything in
> an unwinder is extremely fiddly and difficult to get right)

Indeed, my unwinder also ran into problems, albeit different ones. The first
thing my OpenJDK unwinder tries to do is range check the PC it is presented.
That sounds like the solution, right? Only, in order to do this the unwinder
needs to lookup and cache some JVM state -- i.e. the start and end address of
the region into which JITted code is generated. It has to do this one-off init
lazily from the unwinder itself because this data is dynamically assigned so is
not available when teh unwinder code gets loaded.

The result is that my unwinder gets called with some decidedly dodgy frames
before lazy init has provided the data needed to range check and reject those
frames. Catch 22! If the unwinder naively executes the Python to do the lazy
init then - precisely because these early frame are dodgy -- the stack blows up
(worse, a frame reinit trashes the pending frame leaving a pending gdb crash).

So, I found a hack to detect the potential blow-up and back out. That means I
can now get to the point where I can do the lazy init with a safe frame.
Clearly it would be better if:

  i) things did not blow up

and/or

  ii) the unwinder didn't have to see the dodgy frames

As Tom said elsewhere there is a cluster of different problems here that are
all conniving to make it hard for unwinders to /get/ to the position where they
can know what to do. I'm very happy now that I have found a way of ensuring
/my/ unwinder bypasses the bad inputs. My concern now is not that it cannot be
done but rather the fragility of the mechanism I and other implementors are
relying on. It's hard to say whether this is just a question of fixing a few
bugs or a problem with the current design until it becomes clearer what is
actually breaking and why.

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