dbx strangenesses

[jim frost]

A couple of people have requested that I forward any replies I get to
my question about dbx's odd behavior (confusing breakpoints with
termination).  Since I've lost their addresses, I am forwarding the
following reply to this group.

Thanks to Dave Anderson for such a good response.  I wish Sun had been
so thorough when I had problems with the 386i dbx.

jim frost
madd at bu-it.bu.edu

-- cut here --
Date: Tue, 25 Apr 89 08:47:24 PDT
From: buita!harvard!SGI.COM!davea (David B. Anderson)
Message-Id: <8904251547.AA03906 at quasar.sgi.com>
To: madd at bu-it.bu.edu
Subject: dbx question

Jim:

You write:
>>It would interest me a great deal to find out why dbx sometimes
>>confuses a breakpoint with termination of the program.  For instance:

>>	(dbx) stop in trWriteScreen
>>	[3] stop in trWriteScreen
>>	(dbx) run
>>	Process 23700 (padsu_v2.2b) started
>>	[...]
>>	Process 23700 (padsu_v2.2b) finished
>>	(dbx) quit

>>It did not finish, it hit the breakpoint I had set.  A debugger which
>>confuses termination and breakpoints is less than useful.

>>jim frost
>>madd at bu-it.bu.edu

I can't answer your question directly, since  I'm not sure how to reproduce
the problem.    However, the 3.2 release of IRIX contains a much improved
dbx with *many* bugs fixed and many new features.   Note that one of the
*really serious* bugs fixed relates to interrupts. All released versions of
dbx would do longjmp() on interrupt (meaning, usually, keyboard
control-C).  This could and did lead to corruption of internal data
structures for the obvious reason.   One symptom was dbx forgetting
breakpoints it had set and losing track of them in the
process-being-debugged.

It is quite possible that the problem you report is due to this historical
mistake.

The 3.2 dbx release restricts interrupt by establishing most of the code as
a critical region and only *marking* that the interrupt key was pressed and
doing the longjmp() when it is safe.  The only exceptions are at points
like ``run the process'' where (for the duration of the actual
wait-on-the-running-process call) the interrupt actually does a longjmp()
if the interrupt key is pressed.

>From your posting you seem curious rather than desperate.  I hope that's
true.

I hope this helps!
[ David B. Anderson            Silicon Graphics      (415) 964-1459 x3060 ]
[ USENET: {decwrl!,hplabs!sun!}sgi!davea          Internet: davea at sgi.com ]


PS:  If you have a reproducible problem and want to submit it as a
bug report, you'll need to send a tape with the executable which
exhibits the problem.  Contact your Salesman or the Hotline about how to
do this.   The tape will get, finally, to me.

PPS: If the problem is not reproducible then the explanation above
probably applies and no bug report is needed.