caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: John Skaller <skaller@users.sourceforge.net>
To: Jonathan Bryant <jtbryant@valdosta.edu>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Caml on intel-OSX
Date: Fri, 10 Jun 2005 12:55:25 +1000	[thread overview]
Message-ID: <1118372125.8693.139.camel@rosella.wigram> (raw)
In-Reply-To: <1118361728.17936.17.camel@chunky.valdosta.edu>

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


  reply	other threads:[~2005-06-10  2:55 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-09  5:33 John Skaller
2005-06-09  8:23 ` [Caml-list] " Agustín Valverde
2005-06-09 14:00 ` james woodyatt
2005-06-09 15:27   ` John Skaller
2005-06-09 16:20     ` padiolea
2005-06-09 22:51       ` John Skaller
2005-06-10  0:02         ` Jonathan Bryant
2005-06-10  2:55           ` John Skaller [this message]
2005-06-10  7:10             ` Florian Hars
2005-06-10  0:41         ` Jacques Garrigue
2005-06-10  1:57           ` John Skaller
2005-06-14  0:28           ` Sven Luther
2005-06-10  6:35         ` Stefano Zacchiroli
2005-06-10  9:07           ` John Skaller
2005-06-10 23:39         ` Jon Harrop
2005-06-11 18:39           ` John Skaller
2005-06-11 19:03             ` Jon Harrop
2005-06-12  6:58               ` John Skaller
2005-06-13 19:19             ` [Caml-list] AMD64 ocamlopt bug Xavier Leroy
2005-06-13 19:32               ` John Skaller
2005-06-13 20:18                 ` Damien Doligez
2005-06-13 20:27                 ` John Skaller
2005-06-13 21:01                   ` Anil Madhavapeddy
2005-06-09 23:44       ` [Caml-list] Caml on intel-OSX Jonathan Bryant

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1118372125.8693.139.camel@rosella.wigram \
    --to=skaller@users.sourceforge.net \
    --cc=caml-list@inria.fr \
    --cc=jtbryant@valdosta.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).