[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference clt::cma

Title:DECthreads Conference
Moderator:PTHRED::MARYSTEON
Created:Mon May 14 1990
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:1553
Total number of notes:9541

1514.0. "process crash with DECthread bugcheck" by OSOSPS::NAGAO (Yukari Nagao, West Japan SPS / CS) Mon Mar 31 1997 02:31

Hi,

My Customer uses MAILworks/OSF V2.0 & OSF/1 V3.2C.
One of MAILworks process crashes with core dump and cma_dump.log sometimes.
I cannot know what cause and what timing the process crashes.

Is it not enough system resource or is it application bug?
What mean the following cma_dump.log?

Regards for any help or comments...
Thanks,

Yukari Nagao

============

(The following is a part of cma_dump.log.
As the log file is too long, actually there is on osov05::disk$sps1:[nagao.tmp]

%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: test and set: high order bits corrupt at 0x3ffc01de300
%     
%     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 Thu Mar 27 14:33:59 1997, in pid 10548 under
%  username "root"; argv[0] is "/usr/opt/DMW/bin/mcs"
% The current thread is 1485 (address 0x1379418)
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
  Attributes object 2 "<pthread user(mutex)@0x14005c320>" (0x4ab18)
    Access synchronized by mutex 81
    Scheduling: policy throughput, priority 19; inherit scheduling
    Threads created joinable
    Stack size 21120, guard size 2048
    Mutex type recursive
  Attributes object 3 "<pthread user(thread)@0x43e28>" (0x41f18)
    Access synchronized by mutex 92
    Scheduling: policy throughput, priority 19; inherit scheduling
    Threads created joinable
    Stack size 42240, guard size 2048
    Mutex type fast
  Attributes object 4 "<pthread user(thread)@0x43e08>" (0x41d18)
    Access synchronized by mutex 93
    Scheduling: policy throughput, priority 19; inherit scheduling
    Threads created joinable
    Stack size 42240, guard size 2048
    Mutex type fast
  Attributes object 5 "<pthread user(thread)@0x43de8>" (0x41b18)
    Access synchronized by mutex 94
    Scheduling: policy throughput, priority 19; inherit scheduling
    Threads created joinable
    Stack size 42240, guard size 2048
    Mutex type fast
  Attributes object 6 "<pthread user(thread)@0x43dc8>" (0x41918)
    Access synchronized by mutex 95
    Scheduling: policy throughput, priority 19; inherit scheduling
    Threads created joinable
    Stack size 42240, guard size 2048
    Mutex type fast
  Attributes object 7 "<pthread user(thread)@0x43da8>" (0x41718)
    Access synchronized by mutex 96
    Scheduling: policy throughput, priority 19; inherit scheduling
    Threads created joinable
    Stack size 84480, guard size 2048
    Mutex type fast
Current thread specific data keys:
  Key 1, destructor is 0x120259340
  Key 2, destructor is 0x1202593b0
  Key 3, destructor is 0x120150fd0
  Key 4, destructor is 0x12015bdd0
  Key 5, destructor is 0x1201af3d0
  Key 6, destructor is 0x3ff80507bb0
  Key 7, destructor is 0x1201ee320
  Key 8, destructor is 0x1201b3ab0
  Key 9, destructor is 0x1201d94c0
  Key 10, destructor is 0x1201f4ca0
  Key 11, destructor is 0x1201e9180
Current threads:
  Thread 1 (blocked, timed cond wait) "default thread" (0x3ffc01de9f8)
    Waiting on condition variable 2 using mutex 22; timeout at 
      Thu Mar 27 14:34:52 1997
    Scheduling: throughput policy at priority 19
    Thread specific data: 1: 0x75088, 2: 0x75048, 3: 0x47d88, 4: 0x35c08, 5:
       0x17808, 6: 0x47808
    Stack: 0x0 (default stack)
    !! Thread is not on stack !!
    General cancelability enabled, asynch cancelability disabled
    Current vp is 5, synch port is 6
      VP state is susp: Mach policy throughput, priority 19 (RT kernel), state
        waiting; synch port has 0 messages out of 1
    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 2
  Thread 2 (blocked, timed cond wait) "<pthread user@0x11ffff7c0>" (0x33418)
    Waiting on condition variable 6 using mutex 134; timeout at 
      Thu Mar 27 14:34:18 1997
    Scheduling: throughput policy at priority 19
    Thread specific data: 3: 0x47988, 4: 0x10808, 5: 0x9d808
    Stack: 0x5e000; base is 0x5e000, guard area at 0x51fff
    Detached
    General cancelability enabled, asynch cancelability disabled
    Current vp is 8, synch port is 9
      VP state is susp: Mach policy throughput, priority 19 (RT kernel), state
        waiting; synch port has 0 messages out of 1
    Join uses mutex 133 and condition variable 5; wait uses mutex 134 and
      condition variable 6
    The thread's start function and argument are 0x1201aee30 (0x0)
    The thread's latest errno is 0
  Thread 3 (running) "<pthread user@0x11fffeb50>" (0x32418)
    Scheduling: throughput policy at priority 19
    Thread specific data: 3: 0x46d08, 4: 0xda608, 5: 0xcb008, 6: 0x46108
    Stack: 0xf6000; base is 0xf6000, guard area at 0xdffff
    Detached
    General cancelability enabled, asynch cancelability disabled
    Current vp is 11, synch port is 12
      VP state is <unknown-wait>: Mach policy throughput, priority 19 (RT
        kernel), state waiting; synch port has 0 messages out of 1
    Join uses mutex 146 and condition variable 7; wait uses mutex 147 and
      condition variable 8
    The thread's start function and argument are 0x120204fb0 (0xdaa08)
    The thread's latest errno is 2
  Thread 4 (running) "<pthread user@0x11ffffc98>" (0xcd818)
    Scheduling: throughput policy at priority 19
    Thread specific data: 3: 0x46c08, 4: 0xda208, 5: 0xc9008
    Stack: 0x104000; base is 0x104000, guard area at 0xf7fff
    General cancelability enabled, asynch cancelability disabled
    Current vp is 14, synch port is 15
      VP state is <unknown-wait>: Mach policy throughput, priority 19 (RT
        kernel), state waiting; synch port has 0 messages out of 1
    Join uses mutex 148 and condition variable 9; wait uses mutex 149 and
      condition variable 10
    The thread's start function and argument are 0x120146260 (0x24008)
    The thread's latest errno is 0

     .
     .
     .
     .
     .
     .
     .
     .
     .


T.RTitleUserPersonal
Name
DateLines
1514.1DCETHD::BUTENHOFDave Butenhof, DECthreadsMon Mar 31 1997 08:176
This bugcheck is a symptom of a memory corruption. It is most likely an
application bug -- but of course the bug could be anywhere. Memory corruption
can rarely be analyzed usefully from a bugcheck dump, so the log file is
probably of little value.

	/dave
1514.2KOALA::ANKANIdle words waste timeMon Mar 31 1997 12:346
Could you send me the /var/opt/DMW/logs/mcslog file, so I can have
a look at it. Also, is this a localized Japanese version of
MailWorks?

Oh, and bring this discussion over to abott::mailworks-unix

1514.3OSOSPS::NAGAOYukari Nagao, West Japan SPS / CSMon Mar 31 1997 22:298
Thanks for your reply.

I will escalate this problem with core dump.
There is no record /var/opt/DMW/logs/mcslog at process crash time.
Do I have to attach mcslog?

-Yukari