Throwing processes into the debugger

Throwing processes into the debugger

Post by Mark » Wed, 08 Mar 2000 04:00:00



moo!

    Does UNIX have the windows equivalent of the "int 3" instruction that
will throw a process into the de* (if one exists) or terminate it?
this proved INCREDIBLY useful in the world of assertions, etc ...

    probably version specific, but I'm specifically interested in
Free/Open/NetBSD, Linux (RH), and Solaris 7+.

    Any Ideas?

    Thanks.
    mark.

 
 
 

Throwing processes into the debugger

Post by Andrew Gabri » Thu, 09 Mar 2000 04:00:00




Quote:

>moo!

>    Does UNIX have the windows equivalent of the "int 3" instruction that
>will throw a process into the de* (if one exists) or terminate it?
>this proved INCREDIBLY useful in the world of assertions, etc ...

>    probably version specific, but I'm specifically interested in
>Free/Open/NetBSD, Linux (RH), and Solaris 7+.

I think the nearest would be to abort() which coredumps the process.
If you also want it to continue, then you could fork() first and only
abort() in the child.

You could drop in a system() call which invokes a de* on the running
process. However, you wouldn't leave this in except during your own
debugging, and you shouldn't make any assumptions that other people
running your program have things like de*s or compilers installed.

--
Andrew Gabriel
Consultant Software Engineer

 
 
 

Throwing processes into the debugger

Post by Warren Youn » Thu, 09 Mar 2000 04:00:00



>     Does UNIX have the windows equivalent of the "int 3" instruction that
> will throw a process into the de* (if one exists) or terminate it?
> this proved INCREDIBLY useful in the world of assertions, etc ...

>     probably version specific, but I'm specifically interested in
> Free/Open/NetBSD, Linux (RH), and Solaris 7+.

If you're not interested in letting the program continue, this snippet
will do it:

        #define PORTABLE_INT3() { char* p = 0; *p = 42; }

("Portable" is defined as systems that trap on accessing memory location
0, which applies at least to PC Unixes and Win95 and up.)

If you want to be more elegant, call abort() -- the main problem with
this is that after the de* pops up, you have to unwind the stack to
get back to the actual fault location.  Since this causes a signal, you
will also need a de* that can find its way back from the signal
handler to the code that raised the signal.  Not all Unix de*s can
manage that feat.
--
= Warren -- See the *ix pages at http://www.*port.com/~tangent/ix/
=
= ICBM Address: 36.8274040 N, 108.0204086 W, alt. 1714m

 
 
 

Throwing processes into the debugger

Post by Bjorn Rees » Thu, 09 Mar 2000 04:00:00



>     Does UNIX have the windows equivalent of the "int 3" instruction that
> will throw a process into the de* (if one exists) or terminate it?
> this proved INCREDIBLY useful in the world of assertions, etc ...

In the Unix world you usually either call abort() to generate a core
dump for postmortem analysis in a de*, or you simply run the
program from the de* (assertions are only present in debugging
versions anyways).

A third option is to let your program attach a de* to itself,
which enables you to continue debugging the program (such as you
mention above). Have a look at attach.c in the archive below. It
attaches the gdb de* to the program, and takes care of all the
petty details.

  http://www.veryComputer.com/

 
 
 

Throwing processes into the debugger

Post by Mark » Thu, 09 Mar 2000 04:00:00




> >moo!

> >    Does UNIX have the windows equivalent of the "int 3" instruction that
> >will throw a process into the de* (if one exists) or terminate it?
> >this proved INCREDIBLY useful in the world of assertions, etc ...

> Bottom line is, you can't do this to a process that isn't aware you want
> to do it (aware at the source code level).

    Well, I would be adding this code into the program that is being
compiled ...  For example, we always add a routine like this to our Windows
programs:

    void throwInt3()
    {
        _asm{
            int 3
        }
    }

    the effect of this is to throw an exception that windows catches.  If
there is a de* installed on the system, it launches that, and then you
can resume running the program actually.  If there is no de*, then it
just terminates the process -- This is great in assert dialogs -- you can go
in and see the state of what's going on right now.

    i'll check out some of the things you suggested ...

    thanks!

    mark.

 
 
 

1. Debugger question: Child process

Hello.

        I'm a beginner in the Unix development and I have a
question that doesn't find in my actual documentation.
        Question: How to debug a child process created by
fork() system call that doesn't call exec() system call after
the creation ?

        Exactly, if I have next code:

        . . . if(fork()==NULL) {
                display_child();        /* Child code */
                iterate_child;
              } else . . . /* Parent code */

        If we puts a breakpoint at 'display_child' we can't debug
it because the PC (program counter) of the actual process with
the debugger jump from if condition to next block out of the
if sentence.
        I'm developing in a Linux system and using gdb debugger.
        Please, if anyone knows the solution, send me an e-mail

        Thanks you very much !!
Xavi Roig Gracia

2. RSH problem - solved

3. Debugger, run time checking, attaching to a running process

4. Help with multiple process FD access - more info

5. xldb debugger for C++ on aix ( kills the process being debugged )

6. tacacs

7. Source Level Multi-thread Process Viewer/Debugger for Sun Station - New Version

8. How to grep 3 diff. words?

9. Checkpointing/resuming process state under debugger

10. How to attach debugger with a new process

11. Attaching a debugger to a process

12. Which debugger is window debugger?