From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr 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 4D1EABC69 for ; Sat, 31 Mar 2007 21:32:33 +0200 (CEST) Received: from ipmail02.adl2.internode.on.net (ipmail02.adl2.internode.on.net [203.16.214.141]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l2VJWUF0002462 for ; Sat, 31 Mar 2007 21:32:32 +0200 X-IronPort-AV: E=Sophos;i="4.14,357,1170595800"; d="scan'208";a="104611140" Received: from ppp36-111.lns2.syd6.internode.on.net (HELO [192.168.1.201]) ([59.167.36.111]) by ipmail02.adl2.internode.on.net with ESMTP; 01 Apr 2007 05:02:26 +0930 Subject: Re: [Caml-list] Bug somewhere in Ocaml 3.09.3.rc1? From: skaller To: caml-list@inria.fr In-Reply-To: <1175203929.9294.3.camel@rosella.wigram> References: <1175200818.16694.46.camel@rosella.wigram> <1175203929.9294.3.camel@rosella.wigram> Content-Type: text/plain Date: Sun, 01 Apr 2007 05:32:22 +1000 Message-Id: <1175369542.26387.104.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 460EB74E.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; bug:01 ocaml:01 bug:01 compiler:01 ocaml:01 hmmm:01 afaik:01 compiler:01 diverges:01 diverges:01 inlining:01 ocamllex:01 ocamlyacc:01 ocamllex:01 ocamlyacc:01 On Fri, 2007-03-30 at 07:32 +1000, skaller wrote: > On Fri, 2007-03-30 at 06:40 +1000, skaller wrote: > > I have a weird bug where the Felix compiler is going haywire. > > I need some ideas how to think about what it is. It appears > > to be a bug in Ocaml, not my code. > [] > > > So I think I'm overflowing some boundary, and the Ocaml > > run time is corrupting something. The Felix compiler's fresh > > symbol count is around 16,000 when this happens -- quite a small > > number. The test code is around 500K of source characters, > > or 12,000 lines (half the lines are #line directives). > > Ok, 3.10 fails too .. but I think it might be Marshall .. It's not Marshall, I just turned it off. Hmmm .. no hints from anyone? This problem isn't in the code generator AFAIK, because it occurs on both x86 and x86_64. I have a set of Felix code going like: fun f1() { assert(40+2==42); assert(40L+2L==42L); ... // many more occurrences } f1(); fun f2() { .... for 6000 lines of code, all the same pattern. With a new function added into the library which is not actually used by any of this code and DOES work when tested .. the compiler diverges trying to inline into this function (unrelated to the test code!) If I reduce the number of functions in the test code above by 40% it stops diverging and produces the right answer. Add one more test .. any one .. and it diverges. So my theory is something is overflowing and corrupting something. Despite the fact that the inlining procedure is fragile and has had the divergence problem before, legitimately, and I have no particular reason to believe the current version doesn't diverge .. there is no logical connection between the divergence and the number of assertions being checked in the test case: if the new library function cause divergence, it should do so every time. Over 100 tests compile this code and don't fail. The only test to fail is the one described above, and it is 100 times bigger than any other. So I think this is likely to be a bug in Ocaml, probably in the run time system, and most likely in the garbage collector (but it could be in ocamllex/ocamlyacc). I use ocamllex and ocamlyacc, but otherwise the whole program is pure single threaded Ocaml. No special compilation options (like -unsafe) are used. The only 'constant' sized data structure I use is Hashtbl, which is almost always initialised to size 97. Yes, of course it can be my code, and probably is.. I just have no idea what to look for. -- John Skaller Felix, successor to C++: http://felix.sf.net