[Bug translator/6702] combination of "probe ... if()" and argument refering at return probe causes array overflow error.

["fche at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From fche at redhat dot com  2008-06-27 16:48 -------
> > 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.
> 
> [...]
> 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.

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


-- 


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.