Re: The definition of *bomb*

jlg@cochiti.lanl.gov (J. Giles) writes:


      [...core dumps can be analyzed by source-level debuggers...]


      If the language or the user detects the fault (or intercepts the fault
      when the system detects it) and "handles" the problem by issuing a
      message, cleaning up and closing files, etc., then you have a different
      set of information available. Often enough, the "handler" will destroy
      the very information which is needed to isolate the root cause of the
      problem. So it's not always desirable to use "handlers" - even though you
      would not characterize this as a "bomb"!


Users don't have to use handlers, and they can certainly write their own
(hopefully not ones that destroy context in unrecoverable situations).
Provision for handlers in a language enhances code legibility and
simplifies maintenance (the alternative being the introduction of
level-jumping escapes in code). If users write handlers which destroy
information desired for debugging, that's their fault; how can they be
protected?


As for source-level debuggers, a worthwhile development environment will
include a top-level handler in the runtime which is equivalent in function
to a source-level debugger. Such a handler actually has the advantage over
standard debuggers that one's code doesn't have to cross a process-end
boundary, with whatever tidying-up the OS requires (e.g. closing
files/windows/streams/persistent stores), so the user can examine the
situation in more detail to identify the problem, and often restart the
program. This approach has been common in Lisp environments for years; I
believe some Ada systems have it, and I'm sure many OO languages/systems
have it.


Writing a source-level debugger that works from a core-dump can be
extremely difficult for some modern languages, runtimes, and compiler
techniques (e.g. SML/NJ uses closure-converted CPS throughout, making
source/object correspondence difficult, and the garbage collector moves
code constantly). This is an outstanding problem - how to allow the
compiler maximum freedom in code transformations (which form a larger set
in mathematically sound and typesafe modern languages) while still
preserving information to allow good source-level debugging, in a
space-efficient manner (the option of preserving full information about
every transformation is grossly inefficient).


Nick Haines nickh@cmu.edu
--

Return to the comp.compilers page.
Search the comp.compilers archives again.