Re: Problem with assert in dbLock.c

[Andrew Johnson <anj@aps.anl.gov>]

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 tech-talk@aps.anl.gov
> 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