From: Kilgallen@SpamCop.net Sent: Monday, June 03, 2002 9:41 AM To: Info-VAX@Mvb.Saic.Com Subject: C++ conflict with C hanging in LIB$FIND_IMAGE_SYMBOL ? I am looking at a problem with a process which hangs during LIB$FIND_IMAGE_SYMBOL when a main image written in C attempts to activate a pair of shareable images written in C++. I am curious as to whether anyone who has worked with these languages more than I might have encountered something similar. One can escape from the hang into the debugger with CTRL/C. The image called SHARE_CXX_1 (for purposes of this post) is linked against image SHARE_CXX_2 (yes, using CXXLINKER). Image MAIN_C calls LIB$FIND_IMAGE_SYMBOL specifying a (mangled) entrypoint name in SHARE_CXX_1. That activation seems to go reasonably well, as noted by a proper error signal if image SHARE_CXX_2 is missing. Within LIB$FIND_IMAGE_SYMBOL, however, there is some code in lines 1427 through 1440 (Alpha VMS V7.3 listings kit) to stall if some "other thread" is currently in LIB$FIND_IMAGE_SYMBOL. The identity of a thread is determined by calling the undocumented system service $READ_THREAD_UNQ which fetches a number from the PALcode. There is an exception made if that returns the value zero, which is deemed to not conflict with any thread. I don't have PALcode source, but my guess is that the result returned by undocumented system service $READ_THREAD_UNQ is determined solely by previous calls to undocumented system service $WRITE_THREAD_UNQ. A search of the maps on the listings kit indicates $WRITE_THREAD_UNQ is called by Posix modules within the VMS Executive. If I replace image MAIN_C with something I wrote myself in Bliss presenting the same arguments to LIB$FIND_IMAGE_SYMBOL, there is no hang. My current thoughts are that possibly the CRTL against which MAIN_C is linked is calling the undocumented system service $WRITE_THREAD_UNQ with one value (which gets stored in the lock cell within LIB$FIND_IMAGE_SYMBOL when MAIN_C calls to activate SHARE_CXX_1) and then the CXXRTL calls the undocumented system service $WRITE_THREAD_UNQ with a different value, which does not match the lock cell within LIB$FIND_IMAGE_SYMBOL during the recursive call. For the sake of completeness, although I don't think it is crucial, the recursive call to LIB$FIND_IMAGE_SYMBOL from SHARE_CXX_2 is originating inthe module CXXL$VMS_CXX_EXC, which comes from object library LIBCXXSTD_MA.OLB, presumably the implementation of the C++ Standard Library for VMS. Module CXXL$VMS_CXX_EXC contributes to the LIB$INITIALIZE program section within the SHARE_CXX_2 shareable image. Note that the hang is entered before LIB$FIND_IMAGE_SYMBOL has decided whether or not the target image is already loaded into memory. As it happens, the target image in this case is CMA$RTL defaulted to location SYS$SHARE:.EXE, which is not yet loaded into memory. The entrypoint whose address is being sought is CMA$DELAY. My basis for thinking that LIB$FIND_IMAGE_SYMBOL has caught a conflict in calls to $WRITE_THREAD_UNQ rather than the thread conflict it was designed to catch is that breaking the hung image with Control/C I can get the following: DBG> pthread threads Thread Name State Substate Policy Pri ------ ------------------------- --------------- ----------- ------------ --- 1 default thread running VP 1 SCHED_OTHER 11 DBG> indicating that only a single thread is active. Also, from SDA, I get something like: Process index: 013A Name: TEST Extended PID: 00000F3A ---------------------------------------------------------- Process activated images ------------------------ Image Name Start End Type IMCB -------------------------------------- -------- -------- ------------ -------- MAIN_C 00000000 004F3FFF MAIN 7FF40650 MOUNTSHR 004F4000 005D7FFF GLBL PRT SHR 7FF3ED70 DISMNTSHR 005D8000 00639FFF GLBL PRT SHR 7FF3EB30 LIBOTS 0063A000 006401FF GLBL SHR 7FF3F390 LIBRTL 00702000 007539FF GLBL SHR 7FF40530 DECC$SHR 008C4000 009573FF GLBL SHR 7FF3FF10 DPML$SHR 00958000 0099C9FF GLBL SHR 7FF3FDF0 CMA$TIS_SHR 0099E000 009AC3FF GLBL SHR 7FF3E790 SYS$SSISHR 009AE000 009DE3FF GLBL PRT SHR 7FF40160 DEBUG 009E4000 00B24BFF MRGD SHR 7FF3FCD0 SHRIMGMSG 00B48000 00B4E9FF MRGD SHR 7FF3F080 DECC$MSG 00B50000 00B53FFF MRGD SHR 7FF3E670 DBGTBKMSG 00B54000 00B617FF MRGD 7FF3E550 UCX$IPC_SHR 00B94000 00C151FF MRGD SHR 7FF3E060 TCPIP$ACCESS_SHR 00C16000 00CB69FF GLBL SHR 7FF40410 SHARE_C 00CB8000 00D09FFF MRGD PRT SHR 7FF3EC50 SHARE_CXX_1 09B9A000 09CAD1FF MRGD 7FF3EE90 SHARE_CXX_2 09CAE000 0A0C7BFF GLBL 7FF3E3E0 PTHREAD$RTL 0A0C8000 0A1595FF GLBL SHR 7FF40280 SYS$PUBLIC_VECTORS 81003E78 81005E37 GLBL 7FF3F930 SYS$BASE_IMAGE 81019D90 8102C23F GLBL 7FF3F1A0 Total images = 21 Pages allocated = 2084 SDA> with names changed to protect the innocent.