| 2002 2003 2004 <2005> 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 | Index | 2002 2003 2004 <2005> 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: [Fwd: R3.14.8 testing: epicsMessageQueueTestHost fails on linux-x86] |
| From: | Ralph Lange <[email protected]> |
| To: | [email protected] |
| Date: | Wed, 16 Nov 2005 17:20:13 +0100 |
Marty Kraimer wrote:
I found the cause of the crash.The problem was calling epicsThreadSetPriority from a thread not created via epicsThreadCreate.I committed the change and a change to epicsThreadTest.cpp to test epicsThreadSetPriority.When I run epicsMessageQueueTestHost on solaris it never terminates but does do everthing it should???
Is this the same issue that I reported on Nov 11th for Linux-x86? (See attachment.)
Ralph
--- Begin Message ---
Subject: 3.14.8@Linux: epicsMaxThreadsHost does not return From: Ralph Lange <[email protected]> To: EPICS Core Talk <[email protected]> Date: Tue, 08 Nov 2005 13:13:44 +0100
On my Linux (Debian 3.1; gcc 3.3.5) box:
epicsMaxThreadsHost does not return properly. In most cases it runs almost complete
aragon: .../base/3-14-X > bin/linux-x86/epicsMaxThreadsHost
stackSize 131072
100
200
300
400
500
600
700
800
900
1000
1100
1200
1300
1400
1500
number threads 1533
pthread_create error Resource temporarily unavailable
main terminating
then hangs at this point, probably in a system call (doesn't recognize control chars, has to be killed explicitly with -9).
In other cases, the outputs stops before the "number threads" line with the same behaviour.
In the hanging state, 'ps' shows zillions of threads, which I would consider normal during that test.
I'm aware that this could be rather a Linux configuration problem than really related (or even caused) by the test from base. Nevertheless: Any hint about where I should look further?
Ralph
--- End Message ---