Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Tue, 21 Nov 2006 10:06:40 -0600

Jeff,

Jeff Hill wrote:

I am chasing down an infinite recursion during init that appears to occur on
win32-x86 because of an assert failure in epicsThreadOnce. I suspect that
this is a side effect of a cvs update I did before I committed files on
Friday.



I did commit this change to libCom/osi/os/WIN32/osdThread.c about 2

weeks ago, in epicsThreadOnceOsd():


Index: osdThread.c
===================================================================

RCS file:

/net/phoebus/epicsmgr/cvsroot/epics/base/src/libCom/osi/os/WIN32/osdThread.c,v

retrieving revision 1.52.2.13
retrieving revision 1.52.2.14
diff -u -b -r1.52.2.13 -r1.52.2.14

--- osdThread.c 11 Nov 2005 01:47:07 -0000      1.52.2.13
+++ osdThread.c 10 Nov 2006 20:19:34 -0000      1.52.2.14
@@ -999,10 +999,12 @@

     EnterCriticalSection ( & pGbl->mutex );

-    if ( ! *id ) {
+    if ( *id == 0 ) {
+        *id = -1;
         ( *func ) ( arg );
         *id = 1;
-    }
+    } else
+        assert(*id > 0 /* func() called epicsThreadOnce() with same id */);

     LeaveCriticalSection ( & pGbl->mutex );
 }


The purpose of this assertion is to detect a situation that the posix

version of epicsThreadOnceOsd() is unable to handle or even detect since

posix mutexes are not recursive. This might cause an infinite loop if

assert() calls errlogInit() which calls epicsThreadOnce(), but that

situation could only occur if func() has itself first called

epicsThreadOnce() with the same id.



When attempting to fix that I am seeing a real weird situation where it is
building posix code when EPICS_HOST_ARCH == WIN32-x86.


I have no explanation for that.

- Andrew
--
There is considerable overlap between the intelligence of the smartest
bears and the dumbest tourists -- Yosemite National Park Ranger


Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System