RE: Question on signals with Linux

["Mark Rivers" <rivers@cars.uchicago.edu>]

Andrew,
 
Thanks for the quick reply.
 
The crash was due to SIGSEGV.
 
I don't think the problem is with threads, because it crashes before I have started acquisition, and their thread does not begin to do callbacks to my code until I do.  The interaction of EPICS threads with the Prosilica callback thread is not a problem under Windows at least, it works fine.
 
Mark
 
 

________________________________

From: Andrew Johnson [mailto:anj@aps.anl.gov]
Sent: Mon 12/15/2008 5:13 PM
To: Mark Rivers
Cc: tech-talk@aps.anl.gov
Subject: Re: Question on signals with Linux



Hi Mark,

On Monday 15 December 2008 15:56:59 Mark Rivers wrote:
>
> I am trying to write a driver for the Prosilica Gigabit Ethernet cameras
> under Linux.  They provide a pre-built library for controlling their
> cameras.  One of the notes for this library says the following:
>
> * As the API use some signals internally, it is required to "protect" some
> of your system calls (such as sem_wait)  from been interupted. This can be
> done by calling the system call from within a loop and only exiting from it
> if there was no error or if errno is different from EINTR.
>
> When I run an EPICS application that calls this library it crashes and this
> is the output of gdb:

What is the cause of the crash?  SIGSEGV or SIGBUS?

> (gdb) bt
> #0  0x0808ce33 in SIGAction ()
> #1  0x0821bf4d in ignoreSigAlarm (signal=14) at
>     ../../../src/libCom/osi/os/posix/osdSignal.cpp:109
> #2  <signal handler called>
> #3  0x00110416 in __kernel_vsyscall ()
> #4  0x002ce671 in select () from /lib/libc.so.6
> #5  0x0808d21e in pPvMultiplexer::Body ()
> #6  0x08090e00 in _ThreadFunction ()
> #7  0x003b932f in start_thread () from /lib/libpthread.so.0
> #8  0x002d620e in clone () from /lib/libc.so.6

The EPICS OSI socket implementation can use SIGALRM on some Posix systems to
unblock a thread that is waiting on socket if that OS doesn't automatically
unblock the thread when the socket is shutdown() and close().  That's the
ignoreSigAlarm() handler that you can see in the stack trace above.  Our
handler does appear to pass the signal onto any previously-registered handler
that it replaced, but I'm not sure what the overall effect will be of mixing
our code with some other library that uses signals.  It looks like the
Channel Access client and server code make use of this, and I suspect that
Asyn might too (look for calls to epicsSignalInstallSigAlarmIgnore() to check
that).

You may be hitting a problem due to the fact that Prosilica's library does its
own threading, which could interact with the pthreads that EPICS creates.  Be
careful in any code you write that will be called by their callback threads,
because these threads will not be known to our Posix osdThread code.  Their
threads will not appear in the epicsThreadShowAll() output at all, and
attempts to get an epicsThread ID or name may return unexpected results. 
However this isn't obviously the problem above.

Hope this helps a bit,

- Andrew
--
The best FOSS code is written to be read by other humans -- Harold Welte