Original bug ID: 3908
Reporter: anonymous
Status: closed (set by @xavierleroy on 2011-12-17T11:37:49Z)
Resolution: not fixable
Priority: low
Severity: minor
Version: 3.09.0
Category: ~DO NOT USE (was: OCaml general)
Related to: #3077 #3952
Monitored by: smimram

Bug description

Mike Furr has found a problem with one of the Felix regression
tests on the ia64 platform. It appears to me this is
most likely a bug in the ia64 runtime, and next most likely
a bug in the native code generator for ia64.

The code in question works fine on i386, amd64, ppc and
some other architectures. The program contains no uses
of any C bindings, no use of the Obj module, and no unsafe
array accesses.

The error manifests as:

PATH=bin:"$PATH" LD_LIBRARY_PATH=rtl:"$LD_LIBRARY_PATH" bin/flxg -Ilib
tut/examples/mac126
.. ERROR CODE 0xb
TESTFILE -- ERROR! tut/examples/mac126

during 'make test'.

A segfault results from what appears to be a runaway
loop in the garbage collector:

(gdb) bt
#0 0x40000000002a04e0 in caml_oldify_local_roots ()
#1 0x40000000002a5100 in caml_empty_minor_heap ()
#2 0x40000000002a5360 in caml_minor_collection ()
#3 0x40000000002a1b50 in caml_garbage_collection ()
#4 0x40000000002c5ca0 in caml_call_gc ()
#5 0x40000000002a5100 in caml_empty_minor_heap ()
#6 0x40000000002c5ca0 in caml_call_gc ()
#7 0x40000000002a5100 in caml_empty_minor_heap ()
#8 0x40000000002c5ca0 in caml_call_gc ()
#9 0x40000000002a5100 in caml_empty_minor_heap ()
#10 0x40000000002c5ca0 in caml_call_gc ()
#11 0x40000000002a5100 in caml_empty_minor_heap ()

I don't have access to an ia64, so I am unable to
do much about this.

The fault occurs in a (not uploaded) Debian packaging
for Felix 1.1.1, the original tarball is located here:

http://felix.sourceforge.net/flx_1.1.0_src.tgz

It should build on Unix (or Windows XP64 if Ocaml
supports that, though I haven't tried it).

Yes, it IS possible there is a bug in the source
algorithm -- in fact, there definitely used to be
an unchecked overrun -- however the test is deterministic,
so it should fail on all architectures with the same
word size at least --- it works fine on amd64 and alpha.

[The algorithm DOES contain a potentially infinite
recursion which is supposed to be limited]

The actual algorithm is probably part of the
flx_macro module, since the test is exercising
the macro processor.

It is (just) possible a deep recursion is overflowing
the stack, corrupting memory, and causing the gc to
get stuck. Exactly how this could happen I don't know
(since it doesn't on other platforms). The test
has been around for a long time (over a year I think).

BTW: another possibility -- the compile reads in 'precompiled
header file' of name tut/examples/mac126.par is it exists,
and skips parsing and macro processing in that case. The file
contains the Abstract Syntax Tree dumped using Marshal module.
This WOULD cause a crash if Ocaml or Felix version changed.
However it does check .. and the file should not exist
on a virgin build.

Additional information

Reported by skaller@user.sf.net
Originally found by mfurr@debian.org

Instructions to reproduce:

wget http://felix.sourceforge.net/flx_1.1.0_src.tgz
tar -zxvf flx_1.1.0_src.tgz
cd flx_1.1.0_src.tgz
./configure
make
make test

Relevant code is probably in: src/flx_macro.ml

in particular not in this line:

and expand_type_expr sr recursion_limit local_prefix seq (macros:macro_dfn_t list) (t:typecode_t):typecode_t=

the function argument 'recursion_limit'. The test case is:

tut/examples/mac126.flx

You can compile it separately by

bin/flxg -Ilib tut/examples/mac126

The output is in tut/examples/mac126.* where * is
each of hpp, cpp and par.