On Thu, 27 May 2010 12:58:30 -0700, Rick Flower <[email protected]>
wrote:
> On Fri, 28 May 2010 01:55:25 +0800, Holger Hans Peter Freyther
> <[email protected]> wrote:
>> On 05/28/2010 01:32 AM, Rick Flower wrote:
>> 
>>> I'll look some more.. to see what is causing this.. It's hard to
>>> tell without a stackdump.. 

Ok.. I think I have an idea of what's going on and why sigaction
is different with the 3rd argument.. Here's a snippet that seems to
shed some light on why the sigaction's 3rd argument is zero :

4685/1:                       -> libgst:_gst_usleep(0x4e20, 0x0, 0x0, 0x0)
4685/1: alarm(0)                                        = 0
4685/1: setitimer(ITIMER_REAL, 0xFFBEEA90, 0xFFBEEA80)  = 0
4685/1: sigaction(SIGALRM, 0xFFBEE990, 0xFFBEEA40)      = 0
4685/1: sigprocmask(SIG_BLOCK, 0xFFBEEA30, 0xFFBEEA20)  = 0
4685/1: setitimer(ITIMER_REAL, 0xFFBEEA90, 0x00000000)  = 0
4685/1:     Received signal #14, SIGALRM, in sigsuspend() [caught]
4685/1: sigsuspend(0xFFBEEA10)                          Err#4 EINTR
4685/1: setcontext(0xFFBEE6F8)
4685/1: sigaction(SIGALRM, 0xFFBEE990, 0x00000000)      = 0
4685/1: sigprocmask(SIG_UNBLOCK, 0xFFBEEA30, 0x00000000) = 0
4685/1: setitimer(ITIMER_REAL, 0xFFBEEA80, 0x00000000)  = 0
4685/1:                       <- libgst:_gst_usleep() = 0

This seems to imply that the GST kernel calls _gst_usleep(20000)
and that code in turn is calling usleep (Solaris 8 defines both
HAVE_USLEEP and HAVE_NANOSLEEP) which in turn is doing all of the
signal crap you see above starting with the alarm(0), sigaction,etc.
You can see the return from the _gst_usleep() function at the 
bottom.. I'm going to switch over to using nanosleep with
will behave differently and see if that has any effect as the
manpage for it indicates that it does not mess with any signal
handling,etc.

By the way.. For reference, the truss line I'm using to gather
this up (in the off chance it may be useful for someone else)
is :

% truss -lf -s SIGALRM -u libgst,libsigsegv:: myCoolGSTScript >&foo.log

I'll keep you posted..

_______________________________________________
help-smalltalk mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Reply via email to