Hello,
now, here are the results. You were right, it seems to correlate with perls thread
support on Solaris:
- a perl without thread support runs the script;
- a perl with thread support receives SIGBUS while running the script.
Cores may be dumped or not. The SIGBUS signal immediately terminates anything
including the debugger, so there is no chance to see a stacktrace.
I can catch SIGBUS by a signal watcher, but its callback is never called (even with
an asynchronous watcher), no message is displayed, and truss reports SIGBUS again
and again. The first signal arrives within poll(), and all subsequent ones in calls
of setcontext().
And ... finally I discovered an interesting behaviour: please remember the var
watcher generator:
foreach (1..10)
{
no strict 'refs';
push(@varWatchers, Event->var(var=>\${"var$_"}, cb=>sub {warn "Changed var
$_.\n"}, poll=>'rw'));
}
I accidentally decreased the upper limit and voil�: no SIGBUS! I changed it into
$ARGV[0] and quickly found a critical limit of 7. So any number smaller than 7
works, any number greater than 6 does not. Here, of course, but I verified it on two
very different systems. What may this point to? I run limits 6 and 7 under truss
control. There IS a difference: the terminating variant (limit 7) has an additional
call of lwp_mutex_unlock().
Hm, and there is still a non threaded Linux perl running the script with a
segmentation fault ...
Jochen
