From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 0A235BCAC for ; Sat, 14 May 2005 06:14:29 +0200 (CEST) Received: from ash25e.internode.on.net (ash25e.adl2.internode.on.net [203.16.214.182]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j4E4EQ0K022239 for ; Sat, 14 May 2005 06:14:28 +0200 Received: from [192.168.1.200] (ppp22-114.lns2.syd3.internode.on.net [59.167.22.114]) by ash25e.internode.on.net (8.12.9/8.12.6) with ESMTP id j4E4EIRm067838; Sat, 14 May 2005 13:44:20 +0930 (CST) (envelope-from skaller@users.sourceforge.net) Subject: Re: [Caml-list] AMD64 segfault From: skaller Reply-To: skaller@users.sourceforge.net To: Jon Harrop Cc: caml-list In-Reply-To: <200505130233.27713.jon@ffconsultancy.com> References: <1115937349.17251.8.camel@pelican.wigram> <200505130233.27713.jon@ffconsultancy.com> Content-Type: text/plain Organization: Message-Id: <1116044057.17482.1010.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 14 May 2005 14:14:18 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 42857B22.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 segfault:01 sourceforge:01 stack:01 segfault:01 stack:01 ulimit:01 ulimit:01 noticable:01 ocamlopt:01 glebe:01 meg:98 061:98 wrote:01 wrote:01 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Level: On Fri, 2005-05-13 at 11:33, Jon Harrop wrote: > On Thursday 12 May 2005 23:35, skaller wrote: [] > Yes, the stack overflows much more quickly on AMD64 for me (pure64 Debian vs > stock x86 Debian) and also causes a segfault instead of throwing > Stack_overflow. I've no idea why. Addresses are 64 bits instead of 32 . > Try playing with ulimit to set the stack size and rerunning your program. My ulimit is 8192, or 8Meg -- same as my 32 bit machine which is a bit strange -- but it seems reasonable to me. I tried 16M but it doesn't make any noticable difference. I would suspect the stack size if the program processes smaller files but failed on larger more complex ones, but that doesn't seem to be the case. The fault now appears isolated to a single function call, which suggests the Ocamlopt back end code generator, particularly as introducing a diagnostic sometimes fixes the problem (which would also cause a different instruction sequence to be generated). OTOH a lot of functions get called apparently without error before this point in the program is reached, so perhaps not. -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net