From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1094ba,86e8c626be2471ae X-Google-Attributes: gid1094ba,public X-Google-Thread: 103376,fc050a66c3b5d87d X-Google-Attributes: gid103376,public From: "James Giles" Subject: Debugging (was: F9X twister & ADA) Date: 2000/04/13 Message-ID: #1/1 X-Deja-AN: 610766472 References: <8cctts$ujr$1@nnrp1.deja.com> <38EA0440.1ECBC158@ncep.noaa.gov> <38ED4ECA.ADB698C9@sdynamix.com> <38F28A85.53809F39@sdynamix.com> <38F2C1DC.5538F9F0@research.canon.com.au> <5jJI4.297$PV.9915@bgtnsc06-news.ops.worldnet.att.net> <38F3D1D3.416B3493@research.canon.com.au> <85SI4.4008$fV.338113@bgtnsc05-news.ops.worldnet.att.net> <38F3F803.A4A56259@research.canon.com.au> <38F41313.DAF90E74@research.canon.com.au> <38F53816.3D1F28A6@research.canon.com.au> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc04-news.ops.worldnet.att.net 955649372 12.74.2.33 (Thu, 13 Apr 2000 18:09:32 GMT) Organization: AT&T Worldnet NNTP-Posting-Date: Thu, 13 Apr 2000 18:09:32 GMT Newsgroups: comp.lang.fortran,comp.lang.ada Date: 2000-04-13T00:00:00+00:00 List-Id: Geoff Bull wrote in message <38F53816.3D1F28A6@research.canon.com.au>... >James Giles wrote: > >> >What about buffered io and user defined buffering? >> >> Like all parts of the program's state, those are all still present >> *in* the debugging file. You can inspect them there. > >But I'd prefer it in a place defined by me! >I hate looking at core dumps and, thankfully, since using >Ada I *never* have to - same for Java. (when I was a C/Fortran I >lived in the debugger, I get the impression you are still stuck there ) That sounds very inconvenient to me. If I had to design a replacement for what the system produces as a 'dropfile' or 'core file' (or whatever it's called in your system) it would have to be about the same. It would contain all the data that such things usually contain or it would be inadequate (leaving out important parts of the context of the failure). This apparently happens to you: since you've made it clear that a halted program, in whatever environment you're using, loses the register contents present at the point of failure. What else are you losing? And, if I were forced to invent a browser for going through the corpse of a failed program, it would be very much like a debugger (usually displaying data in terms of the program's source, etc.). The only difference from usual debuggers would be that I would make the core image editable and restartable. That way I could often correct and restart a long running program rather than have to rerun it from scratch after finding the problem. I've done this often on systems that implemented editable and restartable program images. Since most of what is necessary to do would be very similar to what the systems people have already done for core images and debuggers, it would be very inconvenient to have to reinvent it myself. Do you have to do this on a program by program basis? >In any embedded / real time context your proposal is just plain wrong. Not during program development. That's the context I have very clearly been discussing. I have clearly stated that for released code for general naive users, some form of graceful termination is important. For embedded/real-time code (which we haven't discussed before), no form of termination is appropriate: the code has to continue to run (though maybe in an impaired way). You can always invalidate someone's position by changing the context of the discussion, but how does that further any objective analysis of the problem at hand? >Stop dead on exception would be difficult to implement if the >program is multithreaded or distributed across multiple machines? Nope. The thread that fails stops immediately. All others stop at the next rendezvous. Why would that be difficult? What I want is that combination of features which most increases the likelyhood of finding the error quickly and allowing me to continue working (either developing code, or working with my in-house production code). -- J. Giles