Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Mon, 15 Dec 2008 17:13:08 -0600

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System