This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug translator/6702] combination of "probe ... if()" and argument refering at return probe causes array overflow error.
- From: "mhiramat at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sources dot redhat dot com
- Date: 28 Jun 2008 00:05:00 -0000
- Subject: [Bug translator/6702] combination of "probe ... if()" and argument refering at return probe causes array overflow error.
- References: <20080627154801.6702.mhiramat@redhat.com>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From mhiramat at redhat dot com 2008-06-28 00:05 -------
(In reply to comment #3)
[...]
> > However, a process which calls some function like syscall functions
> > will be preempted while executing it, and when the process sleeping,
> > another process can change the flag status. In that case, saved
> > variables still remain on the array.
>
> Yup, we don't want to build up garbage for this scenario. It seems
> to me that the synthetic global arrays that store these values should
> be set up in overwrite mode, with no more than the .return.maxactive()
> slots allocated.
I think overwrite mode can't help us in this situation, because we
can't decide which element can be overwritten except for hooking
thread termination (that is what kretprobe does).
> > The opposite case is worse...
> > return probe can't get the variable because entrance probe didn't save it.
>
> OTOH I think that's a reasonable price to pay. We shouldn't crash of
> course, but the .return-side generated code could *skip* the return
> handler if the incoming parameters weren't saved for whatever reason.
>
> In any case, once we properly implement probe-point-conditions by disarming
> probes on the fly, we won't want to enable the synthetic function-entry
> kprobe constantly while the real kretprobe is disabled by condition.
Sure, until it, I hope pr #5916 will solve this...
--
http://sourceware.org/bugzilla/show_bug.cgi?id=6702
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.