From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 84A30BBAF for ; Mon, 23 Aug 2010 14:13:22 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwBADICckxKfVK2kGdsb2JhbACgKAgVAQEBAQkJDAcRAx+eNponhTcEiXY X-IronPort-AV: E=Sophos;i="4.56,257,1280700000"; d="scan'208";a="55913138" Received: from mail-wy0-f182.google.com ([74.125.82.182]) by mail3-smtp-sop.national.inria.fr with ESMTP; 23 Aug 2010 14:13:22 +0200 Received: by wyj26 with SMTP id 26so8857432wyj.27 for ; Mon, 23 Aug 2010 05:13:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.0.85 with SMTP id 63mr2470677wea.29.1282565573321; Mon, 23 Aug 2010 05:12:53 -0700 (PDT) Received: by 10.216.154.79 with HTTP; Mon, 23 Aug 2010 05:12:53 -0700 (PDT) X-Originating-IP: [110.33.121.216] In-Reply-To: <20100823120503.GH27059@janestreet.com> References: <4C725620.4070803@glondu.net> <20100823120503.GH27059@janestreet.com> Date: Mon, 23 Aug 2010 22:12:53 +1000 Message-ID: Subject: Re: [Caml-list] Segfaults with Dynlink with OCaml 3.11 From: Paul Steckler To: Mark Shinwell Cc: caml-list@inria.fr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam: no; 0.00; segfaults:01 dynlink:01 ocaml:01 steckler:01 steck:01 shinwell:01 camlparam:01 generational:01 gdb:01 backtrace:01 segfaults:01 dynlink:01 gdb:01 segfault:01 23,:98 On Mon, Aug 23, 2010 at 10:05 PM, Mark Shinwell wrote: > It can be a time-consuming task, but double-check all the rules on > http://caml.inria.fr/pub/docs/manual-ocaml/manual032.html are being follo= wed. > For example, watch out for things like variables of type [value] that are > wrongly not protected with CAMLlocal/CAMLparam macros across allocation p= oints > when the variable's contents are needed later, uses of the Field macro as= an > lvalue in a situation where instead Store_field must be used, assigning t= o > generational global roots without using the correct function, etc. =A0Jus= t one > minor transgression could be the cause of a hard-to-find error at some ra= ndom > point during program execution. OK, I'll do an audit of those calls. > Have you tried using gdb to determine the stack backtrace when it segfaul= ts? > Also, if it can be done without disturbing too much code, it might be wor= th > trying to eliminate Dynlink from the program as a test. I've already tried gdb, which is how I learned that the segfault occurs during a call to one of the query functions in my glue module. Oh, we just added the Dynlink stuff. There haven't been any recent crashes until just now. That could be an unhappy coincidence; the real issue might lurk in unrelated code, as you point out. -- Paul