Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Gerd Stolpmann <gerd@gerd-stolpmann.de>
To: Xavier Leroy <Xavier.Leroy@inria.fr>,
	Scott McPeak <smcpeak@cs.berkeley.edu>,
	caml-list@inria.fr
Subject: Re: how to set breakpoint at exception throw?
Date: Sat, 1 Jul 2000 14:57:30 +0200	[thread overview]
Message-ID: <00070115165309.14914@ice> (raw)
In-Reply-To: <20000630150823.24021@pauillac.inria.fr>

On Fri, 30 Jun 2000, Xavier Leroy wrote:
>> [Scott McPeak:] In the debugger, I'd like to put a breakpoint essentially in
>> the 'raise' function.  The idea is to get control whenever an exception is
>> raised, and be able to take a backtrace.
>> Any ideas on how to do this?
>
>Reverse execution is your friend: simply run the program under the
>debugger; if an uncaught exception causes the program to terminate,
>back-step (command "back") once, and voila, you're at the point where
>the exception was raised, and you can examine the backtrace.
>
>If your program traps all exceptions or performs finalization before
>re-raising exceptions, you may have to back-step several times, but
>eventually you'll hit the point where the exception was raised.

This debugging technique should be mentioned in the manual; it is important
enough.

Does reverse execution also work for programs doing I/O, for example reading
from a pipe?

Nevertheless, I have a wish: At least for programs compiled with the bytecode
compiler, an automatic backtrace of uncaught exceptions would be often helpful
(i.e I get a list where the last uncaught exception was raised, and all
locations where it is re-raised in the "with" clause of the "try" statement).
First, this type of error is very frequent, and it would save much time if the
location where the problem occurs were output from the failing program itself.
Second, under some environments it is difficult to run the debugger; not every
program is run from the command-line (CGI programs, for example). Furthermore,
such a feature would help bug searching in production environments: on such
machines, there is usually no debugger installed, and it is sometimes difficult
to reconstruct the failing data case.

For me, such a feature would be more worth than the loss of execution
performance of exceptions. I can imagine that it might be even possible to turn
such a feature dynamically on or off (by setting a hook in the bytecode
interpreter).

For multi-threaded programs, it is sufficient to store the list of uncaught
exceptions for every thread, and to output the list of the failing thread.

Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 100             
64293 Darmstadt     EMail:   gerd@gerd-stolpmann.de
Germany                     
----------------------------------------------------------------------------



  reply	other threads:[~2000-07-02 17:10 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-06-28 23:24 Scott McPeak
2000-06-30 13:08 ` Xavier Leroy
2000-07-01 12:57   ` Gerd Stolpmann [this message]
2000-07-03 15:05     ` Patrick M Doane
2000-07-03 21:43       ` Norman Ramsey
2000-07-06  3:05         ` Michael Hohn
2000-07-04 14:43       ` John Max Skaller
2000-07-04 18:19         ` Gerd Stolpmann
2000-07-05 22:13           ` Jean-Christophe Filliatre
2000-07-06  1:26           ` Max Skaller
2000-07-06 11:23           ` Daniel de Rauglaudre
2000-07-05  1:28   ` Scott McPeak
2000-07-05 21:29 Don Syme

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=00070115165309.14914@ice \
    --to=gerd@gerd-stolpmann.de \
    --cc=Xavier.Leroy@inria.fr \
    --cc=caml-list@inria.fr \
    --cc=smcpeak@cs.berkeley.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox