On Thu, 2005-06-09 at 20:02 -0400, Jonathan Bryant wrote:
> I have OCaml 3.08.3 up an running on an AMD64 box running Mandrake
> 10.0.  It compiled beautifully under GODI (ocamlc. ocamlc.opt, ocamlopt,
> ocamlopt.opt, etc...).  It might be a Debian bug...

I doubt it is a Debian bug. I'm actually running Ubuntu,
and the bug occurs in my local compiled from source
version 3.08.3 and also in the installed binary package,
which is 3.08.2.

It also only manifests in one program, and it causes
a segfault in that program in the exact same place
independently of the input, provided that place
is actually executed.

No other Ocaml programs I have built on the box exhibit
this problem. However, the code works fine as bytecode
and also works on the x86 with native code compiler.
Increasing stack size from 8M to 16M has no effect,
and I don't expect the stack to be deep at the point
in the source the error occurs.

The error actually occurs calling a function with
a lot of arguments from inside a list iteration,
and that function immediately calls another function
by simply dropping some arguments .. a perfect candidate
for optimisation. My guess is the backend code generator
has screwed up keeping track of which registers hold what
data .. a problem which won't occur on the x86 simply
because there aren't enough registers... :)

I have verified this, approximately, by adding
debugging prints at various points -- if the print
is added just early enough the bug goes away.

Presumably the extra call is causing a correct
routine in the backend code generator 
to load/save registers or whatever,
because the call is disabling a faulty optimisation/
register allocation. Any other interesting theory
appreciated ..

The segfault occurs in 'caml_apply5()' somewhere.

If anyone would like to test it on another AMD64 based
system I would be most happy:

wget http://felix.sf.net/flx_1.0.25_src.tgz
tar -zxvf flx_1.0.25.tgz
cd flx_1.0.25
./configure
make

[all the test program compiles segfault ..]

This big is logged in the bug tracker,
but i forget the PR and it's hard to find again,
since i don't know what the disposition is ;(

If someone else can reproduce it/fail to
reproduce it, that would be valuable data,
since the package is quite large (160K LOC),
and I have no idea how to isolate the problem.


-- 
John Skaller, skaller at users.sf.net
PO Box 401 Glebe, NSW 2037, Australia Ph:61-2-96600850 
Download Felix here: http://felix.sf.net