Re: seemingly out of place errors?

[Josh Stone <jistone at redhat dot com>]

On 09/28/2012 09:46 AM, Nicholas Murphy wrote:
> I'm getting errors like the following:
> 
> ERROR: Array overflow, check MAXMAPENTRIES near identifier '$filename'
> 
> ...for a line that is essentially aliasing a string variable:
> 
> filename = $filename
> 
> ...and similarly:
> 
> ERROR: Array overflow, check MAXMAPENTRIES near identifier '$fd'
> 
> ...for:
> 
> if ($fd == 0 && track_utility && !(pid() in redirected_stdin)) {
> 
> Admittedly in the latter case there is a check against an array, but
> it seems to be flagging "$fd" not the array check.
> 
> Is some array simply concurrently overflowing elsewhere?  Why am I
> getting these particular errors?

Are these in .return probes?  That's my best guess; ignore the rest of
this reply if not...

When you read any $var (other than $return) in a .return probe, we
actually save the value on entry.  There are a few ways we do this
depending on context, but one way involves an array/map.  Since that map
doesn't exist in your source, we can only tie the error message to the
$var access which generated that code.

The map entries are supposed to remain balanced - added on entry,
removed on return.  But there are at least a few ways this can fail:

1- If this is a deeply recursive function, deeper than MAXMAPENTRIES,
then the number of saved entries will outgrow the map.  Increasing
MAXMAPENTRIES may help, if you can identify some upper bound.

2- If many instances of that function are simultaneously active for any
other reason, like having MANY threads, the same issue/solution applies.

3- If a thread terminates within that function for any reason, without
going through the return path, then those saved entries will be leaked.
 Increasing MAXMAPENTRIES here will only help if you can limit how often
this occurs.  To solve this generally, we might have to also synthesize
a thread-exit probe to delete these stale entries.


Josh