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

Jim Keniston <jkenisto at us dot ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jkenisto at us dot ibm.com

--- Comment #3 from Jim Keniston <jkenisto at us dot ibm.com> 2010-12-01 22:13:29 UTC ---
(In reply to comment #2)
> > 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.

A longjmp shouldn't cause uretprobe_instances to leak.  See
uretprobe_bypass_instances() in uprobes.c.  Our intent was to handle longjmps
correctly, but we didn't consider that C++ exception handling is a different
beast.

-- 
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]