Experimental Physics and
Industrial Control System

"David Dudley" <[email protected]> · Mon, 19 Nov 2007 13:26:13 -0600

Hi, Andrew,

Yea, I'll be around to bug you for a long, long time.... ;-)

OK, I did:
'gmake clean' (GNU make is not the native make on this machine, and BSD make won't build the software itself).
then 'gmake' to recreate the software package
then a 'gmake -s runtests' (you gonna love, this...)

bash-3.2$ gmake -s runtests
epicsUnitTestTest..........ok                                                
epicsCalcTest..............ok                                                
epicsAlgorithmTest.........ok                                                
epicsMathTest..............ok                                                
epicsStdioTest.............ok                                                
epicsStringTest............ok                                                
epicsTimeTest..............ok                                                
epicsThreadTest............ok                                                
epicsThreadPriorityTest....ok                                                
epicsThreadPrivateTest.....ok                                                
epicsExitTest..............ok                                                
epicsTimerTest.............FAILED tests 2-4                                  
        Failed 3/40 tests, 92.50% okay
ringPointerTest............ok                                                
epicsEventTest.............ok                                                
epicsMutexTest.............ok 2/19^Cgmake[3]: *** [runtests] Interrupt       
gmake[2]: *** [runtests.netbsd-x86] Interrupt
gmake[1]: *** [libCom/test.runtests] Interrupt
gmake: *** [src.runtests] Interrupt

bash-3.2$
I then changed the CONFIG.Common file for netbsd, do another 'gmake clean' and then another 'gmake', and got the following:

bash-3.2$ gmake -s runtests
epicsUnitTestTest..........ok                                                
epicsCalcTest..............ok                                                
epicsAlgorithmTest.........ok                                                
epicsMathTest..............ok                                                
epicsStdioTest.............ok                                                
epicsStringTest............ok                                                
epicsTimeTest..............ok                                                
epicsThreadTest............ok                                                
epicsThreadPriorityTest....ok                                                
epicsThreadPrivateTest.....ok                                                
epicsExitTest..............ok                                                
epicsTimerTest.............FAILED tests 2-4                                  
        Failed 3/40 tests, 92.50% okay
ringPointerTest............ok                                                
epicsEventTest.............ok                                                
epicsMutexTest.............ok                                                
epicsExceptionTest.........ok                                                
epicsMessageQueueTest......^Cgmake[3]: *** [runtests] Interrupt
gmake[2]: *** [runtests.netbsd-x86] Interrupt
gmake[1]: *** [libCom/test.runtests] Interrupt
gmake: *** [src.runtests] Interrupt

bash-3.2$ 

Got farther, but not all the way.  I assume that the MessageQueueTest shouldn't take 'minutes', as none of the others took over at most about 5-10 seconds.

Not sure what the timer test failing is.  It was working before, and looks like an upgrade must have killed it.  Also, it isn't very consistent.  I've seen it fail tests 2-5, 2-4, and 2-3 at various times.  The MessageQueTest runs for quite a while, and then I killed it.

David Dudley

>>> Andrew Johnson <[email protected]> 11/19/2007 10:38 AM >>>
Hi David,

Glad that you're still around.

David Dudley wrote:
> Now, whenever I start the system, I get the following message, and
> things "die" - as I would expect they would-:
> 
> â------------------------------------------------------------------------------------
> A call to "assert (status==epicsMutexLockOK)" failed in ../dbLock.c line 247.
> EPICS Release EPICS R3.14.9 $R3-14-9$ $2007/02/05 16:31:45$.
> Current time Mon Nov 19 2007 09:38:29.509300158.
> Please E-mail this message to the author or to [email protected] 
> Calling epicsThreadSuspendSelf()
> Thread scan2 (0xbb630880) suspended
> â------------------------------------------------------------------------------------
> 
> The same software operates without incident on my Linux development
> system, so I'm assuming it's something related to support under
> NetBSD that's the culprit.  I'll start looking, but can anyone give
> me a pointer on where to start?

There are two completely different implementations of the epicsMutex 
primitives defined in src/libCom/osi/os/posix/osdMutex.c which are 
selected depending on whether your version of pthreads implements 
recursive mutexes or not.

Our build system selects the simpler version on both Solaris and Linux 
(where presumably recursive mutexes are supported), but the more complex 
one on Darwin.  You might want to remove the -D_XOPEN_SOURCE=500 from 
your configure/os files for NetBSD if you have it defined as this might 
solve the problem.

I would suggest typing 'make -s runtests' from the top of your build 
tree and see whether it passes all of the libCom test code â maybe do 
that first, then change your configure/os area to see if there's any 
difference...

- Andrew
-- 
When a distinguished but elderly scientist states that something is
possible, he is almost certainly right.  When he states that something
is impossible, he is very probably wrong.  -- Arthur C. Clarke

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System