Very Computer

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.

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

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

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/

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.

Very Computer

Throwing processes into the debugger

Throwing processes into the debugger

Throwing processes into the debugger

Throwing processes into the debugger

Throwing processes into the debugger

Throwing processes into the debugger