[omniORB] omniORB 3.0 eg1 crashes on VMS Alpha

[Bruce Visscher]

Hello omniORBers,

I have finally compiled the 3.0 snapshot (the sources I'm using are
current as of the OMNIORB3-19991005 tarball) on OpenVMS Alpha 7.1 using
Compaq C++ 6.2.

However, src/examples/echo/eg1 crashes.  As requested, here's the stack
trace:

> 
> sysy2k[.EXAMPLES.ECHO]> mcr []eg1.exe
> I said, "Hello!".
> The Echo object replied, "Hello!".
> omniORB: Assertion failed -- mutex should not be held.
>  This is a bug in omniORB. Please submit a report (with stack
>  trace if possible) to <omniorb@uk.research.att.com>.
>    file: OMNIROOT:[OMNIORB3-19991005.SRC.LIB.OMNIORB2.ORBCORE]OMNIINTERNAL.CC;1
>    line: 275
> %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000000000
> 0000, PC=000000000047CDFC, PS=0000001B
> %TRACE-F-TRACEBACK, symbolic stack dump follows
>   image    module    routine             line      rel PC           abs PC      
>  OMNIORB3_RT  TRACEDTHREAD  assert_held
>                                         20518 000000000000078C 000000000047CDFC

tracedthread.cc line 144.

>  OMNIORB3_RT  OMNIINTERNAL  releaseObjRef
>                                         22078 0000000000002B28 000000000042A278

omniinternal.cc line 276

>  OMNIORB3_RT  BOOTSTRAP_I  ~serviceRecord
>                                         21796 0000000000002FB0 0000000000495400

bootstrap_i.cc line 86

>  OMNIORB3_RT                                0 000000000010AE18 00000000004A8E18
>  OMNIORB3_RT                                0 000000000010AEAC 00000000004A8EAC
>  OMNIORB3_RT  BOOTSTRAP_I  __fini_BOOTSTRAP_I_CC_4_c5f2f856_00000001
>                                         21801 0000000000003118 0000000000495568

bootstrap_i.cc line 91.

>                                             0 FFFFFFFF8090D19C FFFFFFFF8090D19C
>                                             0 FFFFFFFF80058EA0 FFFFFFFF80058EA0
>  PTHREAD$RTL                                0 000000000005EAA8 00000000001F4AA8
>  PTHREAD$RTL                                0 000000000004C298 00000000001E2298
>  PTHREAD$RTL                                0 000000000003D3E4 00000000001D33E4
>                                             0 0000000000000000 0000000000000000
>  PTHREAD$RTL                                                 ?                ?
>                                             0 FFFFFFFF95C61118 FFFFFFFF95C61118

Looks like an order of initialization problem to me.  Which isn't
surprising.  I guess the good news is that if you can get it right on
OpenVMS it should work anywhere (OpenVMS has the most unforgiving rules
imaginable for deciding which initialization code gets run between
translation units).

BTW, I like the implementation of BOMB_OUT().  Yes, I think throwing a
de-referenced null pointer should get somebody's attention!

I'll continue to debug this, but I thought I'd post the stack trace in
case someone knows what the culprit is.

Bruce Visscher