[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2007-03-31 (19:32) |
From: | skaller <skaller@u...> |
Subject: | Re: [Caml-list] Bug somewhere in Ocaml 3.09.3.rc1? |
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 <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net