madd@adt.UUCP (jim frost) (04/26/89)
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@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@quasar.sgi.com> To: madd@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@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@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.