Conference clt::cma

1530.0. "NSR crashes after DCE installation on UNIX V3.2D-2" by MUNICH::SBECKER (Every minute - every hour, I feel the power) Fri Apr 25 1997 08:21

    Hi all,
    
    customer installed on a NSR client (Unix V3.2(41.64) = V3.2D-2) DCE V1.3.B.
    
    After this he can't no more do a NSR backup.
    
    He gets DECthread crashes like this one:
    
     Detailinformationen ( Log Files, ... ):
     ---------------------------------------
    %DECthreads bugcheck (version V3.12-311), terminating execution.
    % Running on DEC OSF/1 AXP [OSF1 alpha V3.2(41.64); cpu type 41,
    configured for
    %  2 cpus, 2 cpus in box, 1023Mb]
    % Reason: Activation of DECthreads attempted after creating TIS
    mutexes.
    %
    % The bugcheck occurred at Fri Apr 18 10:16:47 1997, in pid 8344 under
    username
    %  "root"; argv[0] is "/usr/bin/savefs"
    % 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: 0x11fffebb8 (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" (0x1400309f0) is not locked
      Mutex 2 (fast) "known attr list" (0x140030d10) is not locked
      Mutex 3 (fast) "known mutex list" (0x140030db0) is not locked
      Mutex 4 (recursive) "global lock" (0x140030e50) is not locked
      Mutex 5 (fast) "32 byte VM lookaside" (0x140030ef0) is not locked
      Mutex 6 (fast) "128 byte VM lookaside" (0x140030f90) is not locked
      Mutex 7 (fast) "176 byte VM lookaside" (0x140031030) is not locked
      Mutex 8 (fast) "752 byte VM lookaside" (0x1400310d0) is not locked
      Mutex 9 (fast) "3216 byte VM lookaside" (0x140031170) is not locked
      Mutex 10 (fast) "4208 byte VM lookaside" (0x140031210) is not locked
      Mutex 11 (fast) "attributes object cache" (0x1400312b0) is not locked
      Mutex 12 (fast) "thread cache" (0x140031350) is not locked
      Mutex 13 (fast) "small stack cache" (0x1400313f0) is not locked
       Mutex 14 (fast) "default stack cache" (0x140031490) is not locked
      Mutex 15 (fast) "large stack cache" (0x140031530) is not locked
      Mutex 16 (fast) "VM stats" (0x1400315d0) is not locked
      Mutex 17 (fast) "per-thread context" (0x140031670) is not locked
      Mutex 18 (fast) "known cond list" (0x140031710) is not locked
      Mutex 19 (fast) "atfork queue" (0x1400317b0) is not locked
      Mutex 20 (fast) "one time init" (0x140031850) is not locked
      Mutex 21 (fast) "thread 1 lock" (0x140031990) is not locked
      Mutex 22 (fast) "thread 1 wait" (0x140031ad0) is not locked
      Mutex 23 (fast) "<once block@0x300401a8658>" (0x140031cb0) is not
    locked
      Mutex 24 (fast) "<pthread user@0x300401dc970>" (0x140031d50) is not
    locked
      Mutex 25 (fast) "<once block@0x300401a9120>" (0x140031df0) is not
    locked
      Mutex 26 (fast) "<pthread user@0x300401dc9a0>" (0x140031e90) is not
    locked
      Mutex 27 (fast) "<pthread user@0x140043ae0>" (0x140031f30) is not
    locked
    Current condition variables:
      Condition variable 1, "thread 1 join" (0x140031a30) has no waiters
      Condition variable 2, "thread 1 wait" (0x140031b70) 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) 15 in use, 0
    free;
          maximum free 0; 0 hits, 15 misses (0.00% hit rate); high water
    mark is 6;
          2 adjust intervals (plus 1 iteration); current balance 1, trend
    is up
          (for 1 interval)
        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
        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)
        31 external calls for 4464 bytes; 31 current allocations, 4464
    bytes
    Kernel threads:
      VPa 0x1400318f0: port 5, synch 6, seq 1, flags:  running, default
    
    
    
    Is this a known problem, has anybody seen this before ?
    
    What else should I look for please ?
    
    This only happens on the client where DCE is installed.
    
    
    Many greetings
    
    
    Sigi, DSC Munich
    
    
    
    

This means that some library in the process started using TIS mutexes before
the DECthreads library was initialized. Prior to Digital UNIX 4.0, that was
illegal and unsupportable. The process cannot continue, because the TIS
mutexes wouldn't work. They're fakes, created for a nonthreaded process, and
cannot be "fixed up" to work with multiple threads.

This might happen, for example, if libpthreads.so were to be dynamically
loaded after libc had already been initialized. But, depending on how all the
pieces were linked, it could happen even with normal program loading. I know
that SIA distributed security software would do this -- it uses DCE
"transparently" when innocent nonthreaded programs (like ls) ask about user
and group information, which dynamically activates threads. This can result
in all sorts of bizarre behavior. But apparently, amazingly, it actually
worked sometimes.

It is a requirement that, to use libpthreads within a process, the MAIN
PROGRAM must have been linked with a direct and explicit dependency on the
threads libraries. You cannot link a nonthreaded main program and have it run
with a threaded library.

We've removed this restriction for Digital UNIX 4.0, except for a few
remaining details around libexc/libc interactions, and errno. (Which we're
still hoping we can get the appropriate people to clean up, eventually.) Most
importantly, now that POSIX allows static initialization of mutexes, we were
able to set up TIS so that it uses "real" mutexes, that can continue to be
used after thread initialization. Therefore, under 4.0 or later, you wouldn't
see this particular problem.

Nevertheless, what you're doing is unsupportable, and the only solution is to
stop doing it.

	/dave

    Thank you very much the excellent and very quick answer !!!!
    
    But does it mean it is not supported to install DCE on a UNIX client
    that wants to do NSR backups, ie. is a NSR client ?
    
    Greetings 
    Sigi

I don't know whether it's "supported to install DCE on a UNIX client that
wants to do NSR backups". That's between DCE and NSR, I guess. The point is
that SIA -- and possibly other components -- have tried to make threads do
things that aren't supported and cannot be supported given the structure of
the system, and what you've seen is one possible symptom of that problem.

If DCE and NSR can make things work without trying to make the system do
things it cannot do, that's fine. Clearly, in this case, someone's doing
something wrong. I don't know what, except for the symptom you showed, and I
don't know who, and I don't know why. It's possible that the culprit wasn't
either DCE or NSR, and you've hit some fluke coincidence in some other
subsystem.

All I can say with reasonable authority based on the information here is that
there is no indication of a DECthreads problem. DECthreads is telling you
that some component broke the process in such a way that it cannot be
initialized safely for multiple threads. If it intended to do that, and
cannot avoid doing that, then it cannot be made to work. If it didn't intend
to do that, then something can presumably be fixed to avoid the problem.

	/dave

    Hi Dave,
    
    thank you very much so long for the replies.
    
    
    Many greetings
    
    
    Sigi