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

Conference turris::digital_unix

Title:DIGITAL UNIX(FORMERLY KNOWN AS DEC OSF/1)
Notice:Welcome to the Digital UNIX Conference
Moderator:SMURF::DENHAM
Created:Thu Mar 16 1995
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:10068
Total number of notes:35879

8756.0. "DBX and -noproc on v4.0B" by RHETT::HALETKY () Fri Feb 07 1997 10:08

    Hello,
    
    We have a cusotmer that has a problem using dbx -noproc on v4.0a and I
    have the same problem on v4.0b. The -noproc option appears to be
    useless.
    
    By setting internal vars we can override the required switch command
    but we can't seem to use the next option. Here is the simple c program
    and we can not seem to step over the next.
    
    main()
    {
            system("ls -al /usr/users/elh");
    
            sleep(100);
    }
    
    
    compiled: cc -g c.c -o c
    I set a break point at 3 and then at 5. do run and the breakpoint can't
    be found anymore.
    
    
    As well, Interrupts are ignored.
    
    
    This is very strange behavior. Any comments as to what is happening?
    
    Best regards,
    Ed Haletky
    Digital CSC
T.RTitleUserPersonal
Name		DateLines
8756.1SMURF::DENHAMDigital UNIX KernelFri Feb 07 1997 11:186
    Yeah, something sure looks busted. Wouldn't be surprised if some
    ptrace signal path didn't get stomped on somewhere, but I'll
    PeterT take a shot at it before I go to far.
    
    My big plan is remove ptrace from the kernel and emulated it with
    /proc! Wonder how that'll go over....
8756.2Fiule a QAR and we'll fix it...SMURF::PETERTrigidly defined areas of doubt and uncertaintyFri Feb 07 1997 12:1425
    Okay, now that I see the program, I have a better idea of what's going
    wrong.  Not that I have an explanation for it, but at least I see
    the problem.  Actually I see a few problems.  First off, this program
    should run fine under /proc.  I spent a lot of time trying to ensure
    that calls to things like system, which do their own fork, are
    not trapped.  But something seems to have broken down there.  Even if
    I set $stop_on_fork to 0, the process seems to get stuck and not
    advance after it correctly finishes the system call.  With -noproc
    set, we seem to be hanging forever in __wait4, which is called 
    indirectly by system, apparently waiting for the shell to finish.
    It looks like the process is not getting reaped correctly.  Perhaps
    dbx has a handle open to it still, and has not closed or reaped
    it, so that system()'s wait on it can never finish.  
    
    I'd recommend filing a QAR on this, and Jeff and I can hash out
    where the blame lies.  I wouldn't be surprised if it's a kernel
    change that dbx has not followed, as we are trying to avoid 
    doing much on dbx.
    
    In the meantime, I'd strongly suggest you try ladebug, as this program
    does not seem to bother it in any way.  Ladebug will eventually 
    replace dbx, so it behooves you to familiarize yourself with it.
    
    PeterT