This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap 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 uprobes/12275] uretprobes break exception handling


http://sourceware.org/bugzilla/show_bug.cgi?id=12275

Josh Stone <jistone at redhat dot com> changed:

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

--- Comment #2 from Josh Stone <jistone at redhat dot com> 2010-12-01 21:06:08 UTC ---
(In reply to comment #0)
> When a uretprobe is placed on a function that throws an exception, the caller
> is unable to catch it.

Roland was not surprised that this fails.  My rough understanding from him is
that C++ dynamically looks at eh_frame data to figure out how to unwind.  It
will see the uretprobe trampoline address on the stack, for which it has no
eh_frame data.  So it assumes that we've reached a point of code compiled
without exception handling (kind of correct) and terminates the app.

I think it's fine that the .return probe doesn't fire for this case, but
ideally I think we'll want a new .except probe so script writers can still have
balanced call+return/except semantics if needed.  But our #1 priority needs to
be getting out of the way of the app's normal execution.

(In reply to comment #1)
> We were discussing how this relates to the longjmp case, seeing that also has
> "strange" stack frames. But a simple example works fine.

In this case the app is fine, so it's much less worrisome.  The .return probe
doesn't fire, which is semantically correct, but we also need to make sure that
uretprobes still cleans up sanely after having been so gracefully avoided.  My
guess is that we'll leak a uretprobe_instance, recovered once the app exits,
but I need to get more familiar with the uretprobes bookkeeping.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


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