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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by sympa.inria.fr (Postfix) with ESMTPS id F3F987ED34 for ; Mon, 16 Jul 2012 15:51:24 +0200 (CEST) Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of mrchebas@gmail.com) identity=pra; client-ip=209.85.214.54; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="mrchebas@gmail.com"; x-sender="mrchebas@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail4-smtp-sop.national.inria.fr: domain of mrchebas@gmail.com designates 209.85.214.54 as permitted sender) identity=mailfrom; client-ip=209.85.214.54; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="mrchebas@gmail.com"; x-sender="mrchebas@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-bk0-f54.google.com) identity=helo; client-ip=209.85.214.54; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="mrchebas@gmail.com"; x-sender="postmaster@mail-bk0-f54.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4BAAkcBFDRVdY2kGdsb2JhbABFuSwIIgEBAQEJCQ0HFAQjgjkCLAEbHgMSCQddAREBBQEiNYdbAQMMmwGCYQkDjCOCcYRXChknDVeIcQEFDJF7A5U7jik+hAA X-IronPort-AV: E=Sophos;i="4.77,594,1336341600"; d="scan'208";a="150792679" Received: from mail-bk0-f54.google.com ([209.85.214.54]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 16 Jul 2012 15:51:24 +0200 Received: by bkcje9 with SMTP id je9so6047524bkc.27 for ; Mon, 16 Jul 2012 06:51:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Ry01UhIw4qjGO4qbrKF2g3eH8EuxfD7jds6fRBK9qOY=; b=scs1vvTlV5LV9MF9wKY+g9geiqKJDnbQ5GmY2xCFnEi5ArWxAUvPiYV6tnL4tqpgjU dxxywmUOQhJpzEZjLfpenLICN8IiLI3VlCbnmeAdVS39iYtRMOBBrvCA3sdx7IFePlJt JyFkyqc63F1nlY6JKstkYSVyIUllarrZu6AA375d1pJ4EqsKfmy5jW37b/da4QOt+baK 4GDySSfigQVKuiDM39t83Fsip7PTaU4yksgl7DFjKE7A40ZGX7zE4U5z8uazjIZ0Q+Sh 2oIt6bzoiyP0nZL23dqqU/17STNHe2B/NjHONJu5m9s48HUEQ8a4136OAjKYvr18PwEx ZPuw== MIME-Version: 1.0 Received: by 10.152.104.171 with SMTP id gf11mr11626466lab.5.1342446683780; Mon, 16 Jul 2012 06:51:23 -0700 (PDT) Received: by 10.112.82.41 with HTTP; Mon, 16 Jul 2012 06:51:23 -0700 (PDT) Date: Mon, 16 Jul 2012 15:51:23 +0200 Message-ID: From: Alexey Rodriguez To: OCaml List Content-Type: multipart/alternative; boundary=f46d04083de7b7756204c4f2b9f6 Subject: [Caml-list] Exception backtraces and stack overflows --f46d04083de7b7756204c4f2b9f6 Content-Type: text/plain; charset=ISO-8859-1 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 --f46d04083de7b7756204c4f2b9f6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I am having trouble understanding exception backtrac= es for stack overflows.

Sometimes the backtrace on= ly 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 t= o 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 pa= th from the Ocaml entry point to the recursive functions that is blowing up= the stack. In these situations the backtrace appears to have "compres= sed" the hundreds of thousands of frames that the recursive calls gene= rated since there is only one entry for List.map.

Is there documentation that explains when you get one b= acktrace 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. May= be the signal handler is skipping over the hundreds of thousands of frames = somehow? If someone can=A0elucidate=A0this mystery for me I'll be very = grateful!

I can provide more details if needed, but probably some= one 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. T= his might be expensive as Not_found is raised by many functions in the stan= dard 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 o= riginal inputs to trigger the bug in a debug build.

Thanks!

Alexey
--f46d04083de7b7756204c4f2b9f6--