Conference turris::c_plus_plus

3581.0. "Activation of DECthreads attempted after creating TIS mutexes: java v1.0.2 to C++ v5.5 to ObjectBroker v2.7.11" by NNTPD::"[email protected]" (Paul Healy) Wed May 21 1997 11:03

I am trying to makes calls on an ObjectBroker (2.7.11) DEC C++ (v5.5)
client from a Java (v. osfjdk1.0.2-decunix32) program, running on 
Digital Unix v3.2. 

Translated this means, the jvm loads a .so which is linked with 
all of the user written C++ and associated libraries (I hope).

It dies with this message:

%DECthreads bugcheck (version V3.12-311), terminating execution.
% Running on DEC OSF/1 AXP [OSF1 alpha V3.2(148); cpu type 35, configured for
1
%  cpu, 1 cpu in box, 255Mb]
% Reason: Activation of DECthreads attempted after creating TIS mutexes.
% See 'cma_dump.log' for state information.

The build environment for this is complicated. I have verifed
that the bits work separately, i.e. java to .so works on its own (with
no ObjectBroker bits), and the ObjectBroker client/server stuff in C++
is fine as well. I am not doing anything with threads.

The link command to create the .so looks like this:

/usr/lib/cmplrs/cc/ld -o libZServer.so -L/usr/lib/cmplrs/cxx \
-rpath /usr/lib/cmplrs/cxx -L../../../lib -shared \
/usr/lib/cmplrs/cc/crt0.o /usr/lib/cmplrs/cxx/_main.o \
./cxx_repository/CORBAClientFacade__T10ZServer.o \
./cxx_repository/basic_string__Tc22string_char_traits__Tc13allocator__Tc.o \
ZServer.o ZServerStub.o -lZServer -lih -lobbcxx -lobb \
-lobbcos -lmd5 -lcxxstd -lcxx -lexc -lots -lc 

Any suggestions? cma_dump.log appended.

Paul

[email protected]
--
%DECthreads bugcheck (version V3.12-311), terminating execution.
% Running on DEC OSF/1 AXP [OSF1 alpha V3.2(148); cpu type 35, configured for
1
%  cpu, 1 cpu in box, 255Mb]
% Reason: Activation of DECthreads attempted after creating TIS mutexes.
%     
%     The DECthreads library has detected an inconsistency in its internal
%   state and cannot continue execution. The inconsistency may be due to a bug
%   within the DECthreads library, the application program, or in any library
%   active in the address space. Common causes are unchecked stack overflows,
%   writes through uninitialized pointers, and synchronization races that
%   result in use of invalid data by some thread.
%     Application and library developers are requested to please check for
%   such problems before reporting a DECthreads library problem.
%     The information in this file may aid application program, library, or
%   DECthreads developers in determining the state of the process at the time
%   of this bugcheck. When the problem is reported, this information should be
%   included, along with a detailed procedure for reproducing the problem, if
%   that is possible. The 'detailed procedure' most likely to be of use to
%   developers is a complete program.
% 
% The bugcheck occurred at Wed May 21 14:35:57 1997, in pid 20786 under
%  username "phealy"; argv[0] is null
% The current thread is 1 (address 0x3ffc01de9f8)
Current attributes objects:
  Attributes object 1 "default attr" (0x3ffc01de600)
    Access synchronized by mutex 1
    Scheduling: policy throughput, priority 19; inherit scheduling
    Threads created joinable
    Stack size 21120, guard size 2048
    Mutex type fast
Current thread specific data keys:
  No keys found
Current threads:
  Thread 1 (running) "default thread" (0x3ffc01de9f8)
    Scheduling: throughput policy at priority 19
    No thread specific data
    (*)Stack: 0x11fffd2f8 (default stack)
    General cancelability enabled, asynch cancelability disabled
    No current vp
    Join uses mutex 21 and condition variable 1; wait uses mutex 22 and
      condition variable 2
    The thread's start function and argument are unknown
    The thread's latest errno is 0
Current mutexes:
  Mutex 1 (fast) "default attr's mutex" (0x140254190) is not locked
  Mutex 2 (fast) "known attr list" (0x140254230) is not locked
  Mutex 3 (fast) "known mutex list" (0x1402542d0) is not locked
  Mutex 4 (recursive) "global lock" (0x140254370) is not locked
  Mutex 5 (fast) "32 byte VM lookaside" (0x140254410) is not locked
  Mutex 6 (fast) "128 byte VM lookaside" (0x1402544b0) is not locked
  Mutex 7 (fast) "176 byte VM lookaside" (0x140254550) is not locked
  Mutex 8 (fast) "752 byte VM lookaside" (0x1402545f0) is not locked
  Mutex 9 (fast) "3216 byte VM lookaside" (0x140254690) is not locked
  Mutex 10 (fast) "4208 byte VM lookaside" (0x140254730) is not locked
  Mutex 11 (fast) "attributes object cache" (0x1402547d0) is not locked
  Mutex 12 (fast) "thread cache" (0x140254870) is not locked
  Mutex 13 (fast) "small stack cache" (0x140254910) is not locked
  Mutex 14 (fast) "default stack cache" (0x1402549b0) is not locked
  Mutex 15 (fast) "large stack cache" (0x140254a50) is not locked
  Mutex 16 (fast) "VM stats" (0x140254af0) is not locked
  Mutex 17 (fast) "per-thread context" (0x140254b90) is not locked
  Mutex 18 (fast) "known cond list" (0x140254c30) is not locked
  Mutex 19 (fast) "atfork queue" (0x140254cd0) is not locked
  Mutex 20 (fast) "one time init" (0x140254d70) is not locked
  Mutex 21 (fast) "thread 1 lock" (0x140254eb0) is not locked
  Mutex 22 (fast) "thread 1 wait" (0x140254ff0) is not locked
Current condition variables:
  Condition variable 1, "thread 1 join" (0x140254f50) has no waiters
  Condition variable 2, "thread 1 wait" (0x140255090) has no waiters
Current stacks:
  Thread 1 stack: 0x4000000 to 0x11fffffff (469762047 bytes)
Current memory:
    lookaside 0 (32 bytes; k-vp) 0 in use, 0 free; maximum free 0; high water
      mark is 6; 0 adjust intervals (plus 0 iterations); current balance 0,
      trend is steady (for 0 intervals)
    lookaside 1 (128 bytes; u-vp, cv, stk, attr, mut) 10 in use, 0 free;
      maximum free 0; 0 hits, 10 misses (0.00% hit rate); high water mark is
6;
      1 adjust interval (plus 3 iterations); current balance 3, trend is up
      (for 0 intervals)
    lookaside 2 (176 bytes; ctx) 0 in use, 0 free; maximum free 0; high water
      mark is 6; 0 adjust intervals (plus 0 iterations); current balance 0,
      trend is steady (for 0 intervals)
    lookaside 3 (752 bytes; tcb) 0 in use, 0 free; maximum free 0; high water
      mark is 6; 0 adjust intervals (plus 0 iterations); current balance 0,
      trend is steady (for 0 intervals)
    lookaside 4 (3216 bytes; cv-meter) 0 in use, 0 free; maximum free 0; high
      water mark is 6; 0 adjust intervals (plus 0 iterations); current balance
      0, trend is steady (for 0 intervals)
    lookaside 5 (4208 bytes; mu-meter) 0 in use, 0 free; maximum free 0; high
      water mark is 6; 0 adjust intervals (plus 0 iterations); current balance
      0, trend is steady (for 0 intervals)
    attributes object: 0 in use, 0 free; maximum free 0; high water mark is 6;
      0 adjust intervals (plus 0 iterations); current balance 0, trend is
      steady (for 0 intervals)
    thread: 0 in use, 0 free; maximum free 0; high water mark is 6; 0 adjust
      intervals (plus 0 iterations); current balance 0, trend is steady (for 0
      intervals)
    small stack: 0 in use, 0 free; maximum free 0; high water mark is 6; 0
      adjust intervals (plus 0 iterations); current balance 0, trend is steady
      (for 0 intervals)
    default stack: 0 in use, 0 free; maximum free 0; high water mark is 6; 0
      adjust intervals (plus 0 iterations); current balance 0, trend is steady
      (for 0 intervals)
    large stack: 0 in use, 0 free; maximum free 0; high water mark is 6; 0
      adjust intervals (plus 0 iterations); current balance 0, trend is steady
      (for 0 intervals)
    26 external calls for 3744 bytes; 26 current allocations, 3744 bytes
Kernel threads:
  VPa 0x140254e10: port 5, synch 6, seq 1, flags:  running, default

[Posted by WWW Notes gateway]

Hi Paul,

I think that the reason that you are getting a DECthreads activation
problem is that you are not linking your C++ shared library properly.
Try running the following command on your system:

        % cxx -threads -nopt -v SomeFile.cxx

Look at the ld command line, and add the missing system libraries to your
link command.  You may also want to remove crt0.o from your link.

Fixing your link should get around the thread activation problem.  However,
you may encounter other problems if both your Java code and C++ code run in
the same process.  This is because the Java 1.0.2 kit uses its own threading
model and so will conflict with the pthreads threading model used by your
C++ code.

The fix for this problem is to upgrade to the Java JDK 1.1 release.  This
release is layered on pthreads and so should work seamlessly with your
C++ threads.  However, you will need to upgrade to Digital Unix V4.0A
(or 4.0B, or ptMin) in order to use the JDK 1.1 release

Harold