From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 225EC7F1AA for ; Wed, 9 Sep 2015 21:59:50 +0200 (CEST) IronPort-PHdr: 9a23:yxZc9hZGuQI8Z9H+FCXVcUz/LSx+4OfEezUN459isYplN5qZpMyzbnLW6fgltlLVR4KTs6sC0LqK9fm8EjVcu96oizMrTt9lb1c9k8IYnggtUoauKHbQC7rUVRE8B9lIT1R//nu2YgB/Ecf6YEDO8DXptWZBUiv2OQc9HOnpAIma153xjLDuvcSPKFwU3nKUWvBbElaflU3prM4YgI9veO4a6yDihT92QdlQ3n5iPlmJnhzxtY+a9Z9n9DlM6bp6r5YTGZPTJPtjCOQERHR7ayFmrPHs4BLKSA/K4noHTk0XlABJCk7L9kLAU4/1oxf948N71CSAJoXOQKw5Q3yM8qhuQRnuwHMOMTI06nr/hNF/iatdplSnqgApkKDOZ4TAHfxyc7nGNesXWWdbFuhMWClIBIX0O4IJA+cbJs5Wsob4rl0I6x2zGV//V6vU1jZUiyqujuUB2OM7HFSbhAE= Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=anders@fugmann.net; spf=Pass smtp.mailfrom=anders@fugmann.net; spf=None smtp.helo=postmaster@gw.fugmann.net Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of anders@fugmann.net) identity=pra; client-ip=90.184.182.235; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="anders@fugmann.net"; x-sender="anders@fugmann.net"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of anders@fugmann.net designates 90.184.182.235 as permitted sender) identity=mailfrom; client-ip=90.184.182.235; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="anders@fugmann.net"; x-sender="anders@fugmann.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@gw.fugmann.net) identity=helo; client-ip=90.184.182.235; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="anders@fugmann.net"; x-sender="postmaster@gw.fugmann.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DvBAChjvBV/+u2uFpRDIJ3LFRpgySweosHhgECgUI8EAEBAQEBAQEBgQmCHYIHAQEEHQYEEQgBATYCDwsYAgIFFgsCAgkDAgECAUUTCAKIKwO1OHGEZQEFgW2NZgaBIopMhCQBNDoXglKBQ4c2jiWFCooCmGYmggOBf2+ISQEBAQ X-IPAS-Result: A0DvBAChjvBV/+u2uFpRDIJ3LFRpgySweosHhgECgUI8EAEBAQEBAQEBgQmCHYIHAQEEHQYEEQgBATYCDwsYAgIFFgsCAgkDAgECAUUTCAKIKwO1OHGEZQEFgW2NZgaBIopMhCQBNDoXglKBQ4c2jiWFCooCmGYmggOBf2+ISQEBAQ X-IronPort-AV: E=Sophos;i="5.17,498,1437429600"; d="scan'208";a="145278112" Received: from gw.fugmann.net ([90.184.182.235]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/ADH-AES256-GCM-SHA384; 09 Sep 2015 21:59:48 +0200 Received: from [IPv6:2001:470:dc46:1:daa2:5eff:fe95:453e] (zaphod.fugmann.net [IPv6:2001:470:dc46:1:daa2:5eff:fe95:453e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by gw.fugmann.net (Postfix) with ESMTPSA id EFB5129238F4 for ; Wed, 9 Sep 2015 21:59:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=fugmann.net; s=mail; t=1441828787; bh=Xu8zKg/bt2TQOlFpY0fifDlXGBbi+ozGIIkso1vrI/c=; h=Subject:Reply-To:References:To:From:Date:In-Reply-To:From; b=h9coRI+wnXF2BCF4Aoqfk0aS+5Am3u+SllJ8j15XbUD1jN/6rdRvyDCQjT37tT44K ukcRcz/opUEJta+TKuyanItmS/b0f4Jrf3gc0x9CPNW1Osdm+1tbIWpmdJB6yV0cjn QKl68zE7G2W6Uguwq1EUFNq3Xb+LvrUk9t86dW4s= Reply-To: Anders Peter Fugmann References: <55F085FE.7010809@fugmann.net> To: caml-list@inria.fr From: Anders Peter Fugmann Message-ID: <55F08FB2.2090103@fugmann.net> Date: Wed, 9 Sep 2015 21:59:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.1.0 MIME-Version: 1.0 In-Reply-To: <55F085FE.7010809@fugmann.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] Exceptions and backtraces 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 >