[net.unix] I HATE DBX! I HATE DBX!

massar@think.ARPA (JP Massar) (03/04/86)

FLAME ON
I've really had it up to you know where with DBX.  The next time it
tells me '<variable> is not active' I think I will list out the code,
tear it into tiny, tiny bits and sprinkle it out over the Charles River...
FLAME OFF

Does anyone have/know-of a REAL, reasonably bug-free, powerful
'C' debugger (public domain or commercial) that runs on VAX BSD4[23]?
Is the 4.3 dbx by any chance new and improved?
        
I will summarize replies.
-- 
-- JP Massar, Thinking Machines Corporation, Cambridge, MA
-- ihnp4!think!massar, massar@think.com
-- 617-876-1111

mp@allegra.UUCP (Mark Plotnick) (03/05/86)

In article <4473@think.ARPA>, massar@think.ARPA rants and raves
("raves" is possibly not the right word to use here) about dbx.

The vanilla 4.2bsd dbx gave "<variable> is not active" errors when you
were stopped inside a nested block because its findframe() routine was
a bit simplistic.  It just walked down (or is it up - we're talking
about a vax here, after all) the stack by following the saved frame
pointers.  Mark Linton, the author, posted a large set of diffs in 1984
that fixed this and many other bugs (briefly, it needs to check if the
current function is an "inline" function, and if so should look at its
"container" rather than blindly calling nextframe()).

One problem I've found in the 1984 version and the 4.3bsd-beta version
is that occasionally dbx will get confused when the PC is in
sigtramp-land (somewhere above your stack base, around the u area).  It
prints the arguments to the current function (in my case, this is
typically a select() that's been interrupted by an alarm or int signal)
correctly, but claims the name of the function is sbrk or printf.  It
then frequently doesn't give a stack trace longer than one function.  If
anyone has a fix for this, let me know.

While we're on the subject of dbx bugs, you may want to change
the restoretty() function to do
	ioctl(fileno(f), TIOCSETN, t);
rather than
	stty(fileno(f), t);
so that when a signal that's not being caught by dbx comes in (for
instance, dbx normally does nothing with an alarm signal except reflect
it back to the process), your pending typein won't get flushed.

	Mark Plotnick
	allegra!mp