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
- Replies:
- RE: EPICS thread problem on cygwin-x86 Mark Rivers
- References:
- RE: EPICS thread problem on cygwin-x86 Mark Rivers
- Navigate by Date:
- Prev:
RE: EPICS thread problem on cygwin-x86 Mark Rivers
- Next:
RE: EPICS thread problem on cygwin-x86 Mark Rivers
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
<2007>
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: EPICS thread problem on cygwin-x86 Mark Rivers
- Next:
RE: EPICS thread problem on cygwin-x86 Mark Rivers
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
<2007>
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|