From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by sympa.inria.fr (Postfix) with ESMTPS id 569F97ED34 for ; Tue, 17 Jul 2012 00:09:13 +0200 (CEST) Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of fabrissimo@gmail.com) identity=pra; client-ip=209.85.214.182; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="fabrissimo@gmail.com"; x-sender="fabrissimo@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail1-smtp-roc.national.inria.fr: domain of fabrissimo@gmail.com designates 209.85.214.182 as permitted sender) identity=mailfrom; client-ip=209.85.214.182; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="fabrissimo@gmail.com"; x-sender="fabrissimo@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ob0-f182.google.com) identity=helo; client-ip=209.85.214.182; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="fabrissimo@gmail.com"; x-sender="postmaster@mail-ob0-f182.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcBANWPBFDRVda2kGdsb2JhbABFuUgIIgEBAQEJCQ0HFAQjgiABAQEEEgIsATgBAwwBBQULAwouIQESAQUBHAYTIodcAwydYAkDjxSFPScNiUgBBQyKTmYVhjIDlTuBEolygyU+gVSCLIFV X-IronPort-AV: E=Sophos;i="4.77,597,1336341600"; d="scan'208";a="167074643" Received: from mail-ob0-f182.google.com ([209.85.214.182]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 17 Jul 2012 00:09:12 +0200 Received: by obbun3 with SMTP id un3so17632042obb.27 for ; Mon, 16 Jul 2012 15:09:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=qAT38xErQcq5BgGo6vg+NZU5q1l0xGTqRXKDI/8+yIU=; b=WL7+/XjPgIpfhi4XPkxnWJwujUDm8HTCjcuVzZ0B2UqPOf8IDWyeqrhTnN/4OaVHFw dFWUt9MKvV5gCrcTeodIpSWjE2FGhJHoI9Fft3zqN5ywq62sMsL6cSHZR+L0rBAmDVAE lHtr9nTJ0PcEMhegTr5lrWdN1Sf14/V/IZwKw0eUK01qD1ntNsPvZuZB9s24lTRmOx7z iNiWcClQG0uv8ODVNe+jcUIIoAM2PVb0dpynwtz+ODHc2ratV1KeEGbnxsiM12IpG/AQ b6+GrfL+dOtSJpomlig6Q6eHfIha5dGkbT8h3K989omOdtFHnAzzVNfj0D8J3gDy4KVB n/sQ== MIME-Version: 1.0 Received: by 10.60.29.38 with SMTP id g6mr12325oeh.45.1342476551239; Mon, 16 Jul 2012 15:09:11 -0700 (PDT) Sender: fabrissimo@gmail.com Received: by 10.76.3.146 with HTTP; Mon, 16 Jul 2012 15:09:11 -0700 (PDT) In-Reply-To: References: Date: Tue, 17 Jul 2012 00:09:11 +0200 X-Google-Sender-Auth: DGi8TVlEyj3PFQHm700UHLqSp14 Message-ID: From: Fabrice Le Fessant To: Alexey Rodriguez Cc: OCaml List Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Caml-list] Re: Exception backtraces and stack overflows The problem for backtraces with SIGSEGV is that the stack trace starts from the last pointer on the stack on which the system can rely, with a corresponding return address in the set of OCaml stack frames. The only such pointer available at the SIGSEGV handler is stored in caml_bottom_of_stack (with the PC in caml_last_return_address), and these pointers are updated only when you do a C call. Since in your program, there is nothing happening before the recursive call, this pointer is never updated during the recursion and the backtrace only contains what was on the stack at the last C call. In your program, you can experiment that by adding "let z = [x] in" before the recursive call in "my_map", this will allocate something, and the GC will be triggered at some point, so that you will get the full backtrace... at least from the point where the GC was called, before the stack overflow. Another funny example is to replace the test in "inc" by : if n mod 100000 = 0 then print_char 'x'; Then, whatever you do, the backtrace will be restricted to : Raised at file "pervasives.ml", line 363, characters 19-39 In fact, the stack overflow did not happen in that function (check using gdb, the backtrace printed by ocaml is actually completely wrong), but in "my_map": "caml_bottom_of_stack" and "caml_last_return_address" point to "print_char", so this location is printed, and then the scan of the stack immediatly stops when it discovers that the stack does not correspond to that (believing that it's probably because -g was forgotten). Maybe this behavior could be improved, at the cost of a more expensive scan of the stack (as done in bytecode), done only in the case of a stack overflow. -Fabrice On Mon, Jul 16, 2012 at 5:06 PM, Alexey Rodriguez wrote: > Hi again, > > A colleague suggested doing the following experiment: call List.map on a > large list and throw an exception from deep down in the call chain. > > Now the backtrace I get contains 1022 entries for map, an entry for the > raise site and some other entry. This matches the 1024 limit of > BACKTRACE_BUFFER_SIZE. Since the limit has been reached, the backtrace is > useless to diagnose the stack overflow. This matches my understanding of > caml_stash_backtrace: all stack frames are inspected and reported as long as > there is space in the trace buffer. > > So it seems there is something funny happening when a stack overflow is > detected in the SIGSEGV handler: there are only 3 trace entries whereas the > stack contains over a hundred thousand frames. Is this intended behavior? > > If it is of any help I am including the test program. I am using Ocaml > 3.12.0 on a x86-64 platform. > > Cheers, > > Alexey > > On Mon, Jul 16, 2012 at 3:51 PM, Alexey Rodriguez > wrote: >> >> Hi, >> >> I am having trouble understanding exception backtraces for stack >> overflows. >> >> Sometimes the backtrace only contains entries for the function that filled >> the stack with frames (you would see many backtrace entries pointing to >> List.map if you were trying to map a very long list). Such traces are >> useless to fix the stack overflow since you cannot use them to find the code >> path that leads to List.map. >> >> In other situations, the backtrace contains the full path from the Ocaml >> entry point to the recursive functions that is blowing up the stack. In >> these situations the backtrace appears to have "compressed" the hundreds of >> thousands of frames that the recursive calls generated since there is only >> one entry for List.map. >> >> Is there documentation that explains when you get one backtrace or the >> other? I tried to understand the source code of caml_stash_backtrace and >> there it seems that all the stack frames are captured (if the backtrace >> buffer size allows). Casual inspection with gdb shows that >> caml_stash_backtrace does not get the full stack at the moment of the fault. >> Maybe the signal handler is skipping over the hundreds of thousands of >> frames somehow? If someone can elucidate this mystery for me I'll be very >> grateful! >> >> I can provide more details if needed, but probably someone on the list can >> already help with this short description. >> >> Oh, one more question on backtraces. I see that when tracing is enabled, >> caml_stash_backtrace is called whenever an exception is thrown. This might >> be expensive as Not_found is raised by many functions in the standard >> library. Is there a high overhead in leaving tracing enabled? This is useful >> in production systems as very often it is not possible to have the original >> inputs to trigger the bug in a debug build. >> >> Thanks! >> >> Alexey > > -- Fabrice LE FESSANT