Re: [Caml-list] Bug somewhere in Ocaml 3.09.3.rc1?

[skaller <skaller@users.sourceforge.net>]

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