Experimental Physics and
Industrial Control System

Eric Norum <[email protected]> · Fri, 27 Apr 2007 14:09:39 -0500

On Apr 27, 2007, at 1:58 PM, Mark Rivers wrote:
Eric,
1) Does putting the epicsThreadSleep(.001); into the thread wrapper
function that actually invokes the EPICS thread fix things?
No. I have simplified the program even more, eliminating the

epicsEvent. I just spawn a thread that either returns immediately or

sleeps for .001 second. The wrapper function now sleeps for 5 seconds

after spawning the thread. It still behaves the same, i.e. if the

spawned thread sleeps for .001 second all is well, and the calling

function sleeps for 5 seconds and prints a message. If it does not
sleep

then it crashes.

I think that I wasn't clear enough about where I meant for the delay
to go.

Here's the code in /src/libCom/osi/os/posix/osdThread.c which I meant
when I referred to the 'wrapper' routine:
static void * start_routine(void *arg)
{
    epicsThreadOSD *pthreadInfo = (epicsThreadOSD *)arg;
    int status;
    int oldtype;
    sigset_t blockAllSig;
 sigfillset(&blockAllSig);

pthread_sigmask(SIG_SETMASK,&blockAllSig,NULL);

status = pthread_setspecific(getpthreadInfo,arg);

checkStatusQuit(status,"pthread_setspecific","start_routine");

status = pthread_setcanceltype
(PTHREAD_CANCEL_ASYNCHRONOUS,&oldtype);

checkStatusQuit(status,"pthread_setcanceltype","start_routine");

status = mutexLock(&listLock);

checkStatusQuit(status,"pthread_mutex_lock","start_routine");

ellAdd(&pthreadList,&pthreadInfo->node);

pthreadInfo->isOnThreadList = 1;

status = pthread_mutex_unlock(&listLock);

checkStatusQuit(status,"pthread_mutex_unlock","start_routine");
 (*pthreadInfo->createFunc)(pthreadInfo->createArg);
 epicsExitCallAtThreadExits ();
    free_threadInfo(pthreadInfo);
    return(0);
}
Does putting the delay just before the free_threadInfo call fix things?

2) Have you tried running this under gdb to see where the crash
occurs?
I have found that gdb under Cygwin does not run the threaded EPICS

applications at all. Maybe I'm doing something wrong, but what
works on

Linux does not work on Cygwin. Furthermore, Cygwin does not produce a

useful core file. It produces a file called, in this case

"threadTest.exe.stackdump", but it simply contains:
$ cat threadTest.exe.stackdump
Exception: STATUS_ACCESS_VIOLATION at eip=004A05B6
eax=DF0DF046 ebx=004E6F60 ecx=6112CB58 edx=005A2DC0 esi=005A2DC0
edi=610E30A0
ebp=0022EDD8 esp=0022EDD4
program=j:\epics\devel\threadTest\bin\cygwin-x86\threadTest.exe, pid
4028, thread main
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame     Function  Args
0022EDD8  004A05B6  (004E6F60, 005A2DC0, 0022EE08, 005A2DC8)
0022EDF8  004918A7  (610E30A0, 004D94F4, 004D9747, 6110A4F0)
0022EE28  0049220E  (004C9438, 0000000A, 00020000, 00401520)
0022EE48  00401593  (00543BD8, 0022EEE8, 00000000, 005407A4)
0022EEF8  00418070  (61157780, FFFFFFFF, 00000000, 004015F3)
0022EF18  0040161E  (00000002, 61157668, 00540090, 77FA88F0)
0022EFD8  61004DD2  (0022EFF0, 00000000, 0022F221, 33323430)
0022FF88  6100594F  (00000000, 00000000, 00000000, 00000000)
End of stack trace
Hmmmmm...
not too useful.
--
Eric Norum <[email protected]>
Advanced Photon Source
Argonne National Laboratory
(630) 252-4793

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System