caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
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
>


  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;
as well as URLs for NNTP newsgroup(s).