On Thu, 27 May 2010 16:19:28 -0700, Rick Flower <[email protected]> wrote:
In looking closer at the dump I provided earlier and comparing it to equivalent processing earlier in the 202Mb log file, I see something at the end I don't see elsewhere : 4685/1: -> libgst:_gst_send_message_internal(0xfac35b80, 0x1, 0xfac02820, 0xfac03458) 4685/1: -> libgst:execute_primitive_operation(0x86, 0x1, 0x0, 0x0) 4685/1: -> libgst:VMpr_Processor_pause(0x0, 0x1, 0x0, 0x0) 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: sigsuspend(0xFFBEEA10) Err#4 EINTR 4685/1: -> libgst:file_polling_handler(0x16, 0x0, 0xffbee6f8, 0xff23c008) 4685/1: -> libgst:_gst_disable_interrupts(0x1, 0x0, 0x0, 0x0) 4685/1: <- libgst:_gst_disable_interrupts() = 1 4685/1: -> libgst:_gst_async_call(0xff2cf020, 0x0, 0x0, 0x0) 4685/1: <- libgst:_gst_async_call() = 0xff2cf020 4685/1: -> libgst:_gst_enable_interrupts(0x1, 0x0, 0x0, 0x0) 4685/1: <- libgst:_gst_enable_interrupts() = 1 4685/1: -> libgst:_gst_set_signal_handler(0x16, 0xff2cfa1c, 0x0, 0x0) 4685/1: sigaction(SIGPOLL, 0xFFBEE518, 0xFFBEE598) = 0 4685/1: <- libgst:_gst_set_signal_handler() = 0xff2cfa1c 4685/1: -> libgst:_gst_wakeup(0x16, 0x0, 0xffbee6f8, 0xff23c008) 4685/1: -> libgst:glthread_in_use(0x0, 0x0, 0x0, 0x0) 4685/1: <- libgst:glthread_in_use() = 0 4685/1: <- libgst:file_polling_handler() = 22 4685/1: setcontext(0xFFBEE6F8) 4685/1: sigaction(SIGALRM, 0xFFBEE990, 0x00000000) = 0 4685/1: sigprocmask(SIG_UNBLOCK, 0xFFBEEA30, 0x00000000) = 0 4685/1: Received signal #14, SIGALRM [default] 4685/1: *** process killed *** Without knowing more about the GST kernel innards, it seems like the VMpr_Processor_pause() is being interrupted by file_polling_handler().. Right after the sigsuspend done as part of _gst_usleep(), the processing is interrupted a new sigaction(SIGPOLL) is called and then the setcontext() is called on behalf of _gst_usleep(). I didn't see that anywhere else and suspect that's a bad sequence of events.. Am I on the right track? I'm not completely sure how file_polling_handler() is used (is it like an interrupt/signal handler or something that can happen asynchronously?) Hope this makes sense.. _______________________________________________ help-smalltalk mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-smalltalk
