From: Anders Peter Fugmann <anders@fugmann.net>
To: caml-list@inria.fr
Subject: Re: [Caml-list] Exceptions and backtraces
Date: Wed, 9 Sep 2015 21:59:46 +0200 [thread overview]
Message-ID: <55F08FB2.2090103@fugmann.net> (raw)
In-Reply-To: <55F085FE.7010809@fugmann.net>
It just occurred to me that the functions I made are tail recursive and
which is why the middle function call is eliminated.
Maybe this should be mentioned in the documentation.
This might also be the reason to why we often see less useful
backtraces, as the chain of function calls are tail recursive.
/Anders
On 09/09/15 21:18, Anders Peter Fugmann wrote:
> Hi,
>
> I'm trying to understand what to expect from backtraces when an
> exception is raised.
>
> The library reference says:
> ---------------
> val print_backtrace : out_channel -> unit
>
> Printexc.print_backtrace oc prints an exception backtrace on the output
> channel oc. The backtrace lists the program locations where the
> most-recently raised exception was raised and where it was propagated
> through function calls.
> ---------------
>
> The documentation seems to suggest that every function call site leading
> up to the exception would be part of the backtrace. However, when I
> execute the following program:
> ---------------
> let trace () =
> let open Printexc in
> get_callstack 2
> |> backtrace_slots
> |> (function Some [| _;s |] -> s)
> |> Slot.location
> |> (function Some l -> l.line_number)
> |> Printf.printf "At Line: %d\n"
>
> exception Stop
> let a () = trace (); raise Stop
> let b () = trace (); a ()
> let () = trace (); b ()
> --------------
> The code produces (both byte and native compilation):
> (ocaml 4.02.3 and 4.03-trunk)
>
> At Line: 13
> At Line: 12
> At Line: 11
> Fatal error: exception Exception.Stop
> Raised at file "exception.ml", line 11, characters 27-31
> Called from file "exception.ml", line 13, characters 21-25
>
> The backtrace does not record the function call at line 12, even though
> the information is there (accessible though 'get_callstack'), so I
> assume that inlining is not causing the behaviour.
>
> Is it expected that the backtrace does not contain a reference for line
> 12, or is there some exception handling optimization I should be aware of?
>
> /Anders
>
next prev parent reply other threads:[~2015-09-09 19:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-09 19:18 Anders Peter Fugmann
2015-09-09 19:59 ` Anders Peter Fugmann [this message]
2015-09-10 9:45 ` Jesper Louis Andersen
2015-09-10 10:54 ` Anders Fugmann
2015-09-10 11:09 ` Jesper Louis Andersen
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=55F08FB2.2090103@fugmann.net \
--to=anders@fugmann.net \
--cc=caml-list@inria.fr \
/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