This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug uprobes/12275] uretprobes break exception handling
- From: "jkenisto at us dot ibm.com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sources dot redhat dot com
- Date: Wed, 1 Dec 2010 22:13:40 +0000
- Subject: [Bug uprobes/12275] uretprobes break exception handling
- Auto-submitted: auto-generated
- References: <bug-12275-1110@http.sourceware.org/bugzilla/>
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.