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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 750227FACB for ; Sat, 6 Sep 2014 00:39:05 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of martin.jambon@ens-lyon.org) identity=pra; client-ip=66.111.4.25; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="martin.jambon@ens-lyon.org"; x-sender="martin.jambon@ens-lyon.org"; x-conformance=sidf_compatible Received-SPF: Neutral (mail2-smtp-roc.national.inria.fr: domain of martin.jambon@ens-lyon.org does not assert whether or not 66.111.4.25 is permitted sender) identity=mailfrom; client-ip=66.111.4.25; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="martin.jambon@ens-lyon.org"; x-sender="martin.jambon@ens-lyon.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@out1-smtp.messagingengine.com) identity=helo; client-ip=66.111.4.25; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="martin.jambon@ens-lyon.org"; x-sender="postmaster@out1-smtp.messagingengine.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8BAN86ClRCbwQZnGdsb2JhbABag2BXtySRbodQAYEDFhABAQEBAQYNCQkUKYQEAQU4CDgCDwsYCRYPCQMCAQIBRRMIAQGIPqkLhgCQMgERBo8GFDoWhDaLOYcLgy+OIBqRa0yCTwEBAQ X-IPAS-Result: Aq8BAN86ClRCbwQZnGdsb2JhbABag2BXtySRbodQAYEDFhABAQEBAQYNCQkUKYQEAQU4CDgCDwsYCRYPCQMCAQIBRRMIAQGIPqkLhgCQMgERBo8GFDoWhDaLOYcLgy+OIBqRa0yCTwEBAQ X-IronPort-AV: E=Sophos;i="5.04,476,1406584800"; d="scan'208";a="93258680" Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Sep 2014 00:39:04 +0200 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by gateway2.nyi.internal (Postfix) with ESMTP id 2D0A820AF0 for ; Fri, 5 Sep 2014 18:39:03 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Fri, 05 Sep 2014 18:39:03 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=FvgzwnsSyHY3h3L2Se5JMX d7nZA=; b=UxVSpFVThkw8S2MmuC4CsyI8e5htLLS43Eg1540+TMuOsWA7NUG1F6 ss8mK4NBu56DIhKmOX6oUuslfZ4C5gfcwRZenyzVSXa6R4RNG4KhWcySbTCMYEL8 N+1jbR+WqoKh6fmtembHS8YcjAxLC02GFSsdaBxrUOiIUOeMrLSmc= X-Sasl-enc: a7hG7lIc3Kq98BI4wgg8gkEV+TuAW9zOVowKADMjjOm9 1409956742 Received: from [172.16.71.136] (unknown [50.193.45.145]) by mail.messagingengine.com (Postfix) with ESMTPA id D18736802A5 for ; Fri, 5 Sep 2014 18:39:02 -0400 (EDT) Message-ID: <540A3B85.6010609@ens-lyon.org> Date: Fri, 05 Sep 2014 15:39:01 -0700 From: Martin Jambon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: caml-list@inria.fr References: <20140905215626.GB3416@annexia.org> <20140905221302.GE3099@annexia.org> <20140905221813.GC3416@annexia.org> In-Reply-To: <20140905221813.GC3416@annexia.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] segfault in simple program with 4.02 native On 09/05/2014 03:18 PM, Richard W.M. Jones wrote: > On Fri, Sep 05, 2014 at 11:13:02PM +0100, Richard W.M. Jones wrote: >> On Fri, Sep 05, 2014 at 06:06:55PM -0400, Ashish Agarwal wrote: >>> I increased the stack size to 65532, which is apparently the max allowed on >>> a Mac, and it doesn't change the behavior. >> >> Yup. I was able to reproduce this on the non-core version, and indeed >> increasing the stack to unlimited on Linux does not help. >> >> The stack trace is simple: >> >> #0 0x00000000004543f4 in camlPervasives__output_string_1198 () >> #1 0x0000000000472093 in camlCamlinternalFormat__output_acc_60624 () >> #2 0x0000000000473a32 in camlPrintf__fun_1062 () >> #3 0x000000000041e776 in camlApp__entry () >> #4 0x000000000041c5f9 in caml_program () >> #5 0x0000000000497f7e in caml_start_program () >> #6 0x000000000049813d in __libc_csu_init () >> #7 0x00007ffff7317d65 in __libc_start_main () from /lib64/libc.so.6 >> #8 0x000000000041c2e9 in _start () >> >> I'm just installing debuginfo so I can get more symbols .. > > .. although I guess the fact that the generated code in config_j.ml is > doing a lot of Obj.magic would be the first place to be suspicious. > > eg: > > let (x : postgres) = > { > host = Obj.magic 0.0; > ... > > where the host field has declared type string. Really? That code is generated by atdgen. What happens is that we have to either create an empty record when starting to parse a list of unordered JSON fields, or use a bunch `let = ref None in` for each field and create the record in the end. While the latter approach is not much more work to implement, the resulting code was found to be significantly slower. The reason why it's using `Obj.magic 0.0` is that it worked in all cases (and has been for the past 4 years). Obtaining a well-formed constant value for any type is not trivial, so this what we have. It's very possible that it's now broken with OCaml 4.02. First try a 'make test' from atdgen's source directory (https://github.com/mjambon/atdgen) and see if it passes. Martin