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

Conference turris::decladebug

Title:Digital Ladebug debugger
Moderator:TLE::LUCIA
Created:Fri Feb 28 1992
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:969
Total number of notes:3959

918.0. "Threads 4.0-30 Crash" by RHETT::HALETKY () Tue Apr 08 1997 16:00

    We have a cusotmer with teh following problem:
    
    Script started on Tue Apr  8 13:56:14 1997
    You have mail.
    cdeman.alf.dec.com [8]> decladebug brk1db
    Welcome to the Ladebug Debugger Version 4.0-30
    ------------------
    object file name: brk1db
    Reading symbolic information ...done
    (ladebug) l 0:37
          1 #include <pthread.h>
          2 #include <errno.h>
          3
          4 #define NT 2
          5 pthread_t threads[NT];
          6 static void *incr_i(void *arg);
          7
          8 void main (void) {
          9         int status;
         10         int exit_value;
         11         int j;
         12
         13         for (j=0;j<NT;j++){
         14                 status = pthread_create (&threads[j],
         15                                          NULL,
         16                                          incr_i,
         17                                          (void *)j);
         18                 if(status < 0) perror("Can't create thread");
         19         }
         20         for (j=0;j< NT; j++) {
         21                 status =
    pthread_join(threads[j],(void*)&exit_value);
         22                 if(status < 0) perror("Can't join thread");
         23         }
         24         exit(0);
         25 }
         26
         27 static void *
         28 incr_i(void *arg) {
         29         int n;
         30         int i=0;
         31
         32         for(n=0;n<1000;n++) {
         33                 i++;
         34                 sleep(1);
         35         }
         36         pthread_exit((void *)0);
         37 }
    (ladebug) ignore SIGTRAP
    when at 33 {print i}(ladebug)
    when at 33 {print i}
    
    [#1: when at "brk1db.c":33 { print i} ]
    (ladebug)
    (ladebug) r
    Unable to create a thread list using decthreads.
    Unable to switch to decthreads mode.
    [1] when [incr_i:33 0x120001808]
    0
    [1] when [incr_i:33 0x120001808]
    0
    
    Ladebug Debugger Version 4.0-30 caught signal "Segmentation fault"
    (11).
    This is an unexpected condition and may indicate the presence of a
    defect.
    If you wish to report this, please include the stack trace that
    follows.
    Diagnostic stack trace ...
    0x12516808
    0x123daf04
    0x123e524c
    0x1235f54c
    0x12237a7c
    0x1220165c
    0x122062d0
    0x121f61d4
    0x121f32dc
    end of diagnostic stack trace.
    Fatal error: Segmentation fault
    cdeman.alf.dec.com [9]> exit
    cdeman.alf.dec.com [10]>
    script done on Tue Apr  8 13:58:32 1997
    
    
    Any ideas?
    
    Best regards,
    Ed Haletky
    Digital CSC
T.RTitleUserPersonal
Name		DateLines
918.1TLE::SHAMIMWed Apr 09 1997 10:0610
First questions is which version of the OS you are running on ??

Secondly, notice that you are ignoring SIGTRAP - this may have something
to do with the problem you are seeing.

We will investigate further and get back to you.

thanks
shamim
918.2SIGTRAP is not the answerRHETT::HALETKYWed Apr 09 1997 13:4112
    Version of OS? v4.0b
    
    Why ignore SIGTRAP? Because if we don't ever time the when line is hit
    the debugger will stop. If you are using when to trace this is not a
    desired effect. ignoring SIGTRAP is a must.
    
    This is a pretty serious problem. Is there a later version of
    decladebug available.
    
    Best regards,
    Ed Haletky
    DIgital CSC
918.3this is how when worksTLE::SHAMIMWed Apr 09 1997 15:2130
>> Why ignore SIGTRAP? Because if we don't ever time the when line is hit
>> the debugger will stop. If you are using when to trace this is not a
>> desired effect. ignoring SIGTRAP is a must.
   

I think you have misunderstood the when functionality.

The when command works as follows: (it is easier to explain by examples)

(ladebug) when at 33 {print i;} 

is telling the debugger that every time the execution reaches line 33, print
the value of variable i. The debugger will not stop as far as the user is
concerned - ie. you will not get the prompt back. Underneath the debuggee
process has to stop when the execution reaches line 33 for the debugger
to get the value of i or perform any other action that is specified in {}.
And whether you say ignore SIGTRAP or not, the debuggee process will stop.

If instead I had said

(ladebug) when at 33 {print i; stop;}

Then in addition to printing the value of variable i when the execution 
reaches line 33, the debugger will also stop and you will get the prompt back.

So to answer your question, it is not at all necessary to ignore SIGTRAP to
use the when command.

thanks
shamim
918.4more infoTLE::SHAMIMWed Apr 09 1997 15:3421
Using your sample program, I can't reproduce the problem on V4.0b.

Also, since you are getting 

>    Unable to create a thread list using decthreads.
>    Unable to switch to decthreads mode.

my suspicion is something is not setup right with the threads library.

Are you running any patches ?? 

Can you give us information (ls -l) on:

/usr/shlib/libpthread.so
/usr/shlib/libpthreaddebug.so

and output of the ladebug command 'listobj'.

thanks
shamim
918.5DCETHD::BUTENHOFDave Butenhof, DECthreadsThu Apr 10 1997 08:0317
>    (ladebug) r
>    Unable to create a thread list using decthreads.
>    Unable to switch to decthreads mode.

I've seen this occasionally. I suspect it has something to do with
initialization state races, although I've never had a chance to isolate it.
(It also happens more with older versions of ladebug, though I have seen it
with 4.0-30.) In any case, for PTmin I've substantially improved the way that
the thread debug library (used by ladebug) deals with uninitialized and
partially initialized libpthread target state -- and I have never seen this
startup problem with the new code.

In the cases where I've seen this problem on older systems, I've always been
able to switch into decthreads mode AFTER initialization. Try setting a
breakpoint in main, and then set $threadlevel="decthreads" when you hit it.

	/dave
918.6TLE::BRETTWed May 21 1997 16:562
ladebugbugs 2203
ipmt HPAQ416AG CLD