From mboxrd@z Thu Jan  1 00:00:00 1970
Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA15073 for caml-redistribution; Mon, 29 Mar 1999 10:13:25 +0200 (MET DST)
Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id VAA11274 for <caml-list@pauillac.inria.fr>; Sun, 28 Mar 1999 21:15:26 +0200 (MET DST)
Received: from postbox.dai.ed.ac.uk (postbox.dai.ed.ac.uk [129.215.41.196])
	by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id VAA21453
	for <caml-list@inria.fr>; Sun, 28 Mar 1999 21:15:25 +0200 (MET DST)
Received: from stilt (stilt.dai.ed.ac.uk [129.215.41.27])
	by postbox.dai.ed.ac.uk (8.8.7/8.8.7) with SMTP id UAA11731;
	Sun, 28 Mar 1999 20:15:23 +0100 (BST)
Date: Sun, 28 Mar 1999 20:14:48 +0100
Message-Id: <14914.199903281914@stilt>
From: William Chesters <williamc@dai.ed.ac.uk>
To: caml-list@inria.fr
Subject: possible instability with native code on UltraSPARC?
Sender: weis

   Has anyone had a problems with stability of native code on
UltraSPARC/Solaris?  When I try my program on the Uni Suns, it crashes
with a bus error or segmentation fault after some number of iterations
of a top level test loop.

   A few random remarks in case anything rings a bell:

   Depending on what I put in the test loop, it crashes anywhere from
the first to the 31st iteration, or not at all; and the place where it
crashes varies between sweep_slice (it seems to have walked off the
end having trashed the `limit' pointer), oldify, and a float array
store in of my modules (most commonly: it can happen in other places
too).  It sometimes behave a little differently under gdb than on its
own.

   With the debug runtime libasmrund.a, it crashes in a different
place but sadly doesn't fail any assertions.

   I haven't so far been able to isolate a single piece of my code
which causes the problem.  However the whole thing is very float-array
intensive, which is probably relatively uncommon in ocaml
applications?

   I tried a few variations of the same code compiled to bytecode, and
didn't see any problems, so it seems not to be in the runtime per se.

   Using -compact with ocamlopt didn't help.  I haven't tried playing
with the -inline.

   I use camlp4 very intensively as a front end, but I don't think
this is a camlp4-related problem, because it happens just the same if
I use pr_o.cmo (which outputs ocaml-syntax ASCII text for ocaml to
parse) as with pr_dump.cmo (which outputs a marshalled syntax tree).

   The only library I am linking with is camlp4's "gramlib.cmxa" which
I use for the lexer (and yes, for what it's worth, I have recompiled
camlp4 and tried again).  That is the only `.cmxa' in the link
command; everything else is one of my `.cmx's.  There are no `.o's or
explicit `-cclib's at all.

   To concentrate my mind, here is a declaration: "I am certain that
there is nothing but ML in the code.  The only compiler involved is
vanilla out-of-the-box ocamlopt 2.02.  The only non-standard library I
am linking with is gramlib.cmxa.  I slept normally last night and have
not ingested coffee for six hours."


   System:

      SunOS stilt 5.6 Generic_105181-11 sun4u sparc  (Sun Ultra 5)

      The Objective Caml compiler, version 2.02
         compiled with gcc version 2.8.1 (*)
         configured to use posix threads for threading (+)

(*) same problem when ocaml compiled with egcs 1.1; N.B. it bootstraps
successfully with either compiler

(+) but the program isn't compiled with -thread or linked with any
thread library