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: 27 Jun 2008 16:36:58 -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-27 16:36 -------
(In reply to comment #1)
> What we have here is a conflict between the rewriting of the
> probe ... if () {}
> block and the
> probe foo.*.return { $saved_variable }
> block.
>
> One possible fix would be to change the latter, so that the synthetic
> probe foo.*.call { save_that_variable }
> probe also gets the same "if ()" condition prepended. That way, the
> data gathering probe is also skipped if the condition is false. That
> sounds rather natural.
In most cases, especially at the short function, it can work.
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. The opposite case is worse...
return probe can't get the variable because entrance probe didn't save it.
I think pr #5916 could solve this issue.
Anyway, IMHO, now what we can do it on older kernels is swapping
the order of probe's if() condition and releasing saved variable block.
--
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.