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 translator/6702] combination of "probe ... if()" and argument refering at return probe causes array overflow error.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]