From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id PAA12732; Sun, 7 Sep 2003 15:37:46 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 PAA12451 for ; Sun, 7 Sep 2003 15:37:44 +0200 (MET DST) Received: from mwinf0402.wanadoo.fr (smtp5.wanadoo.fr [193.252.22.27]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h87DbiT28627 for ; Sun, 7 Sep 2003 15:37:44 +0200 (MET DST) Received: from oops (ARennes-303-1-28-88.w81-53.abo.wanadoo.fr [81.53.112.88]) by mwinf0402.wanadoo.fr (SMTP Server) with ESMTP id CD90B800057; Sun, 7 Sep 2003 15:37:43 +0200 (CEST) Received: from david by oops with local (Exim 3.35 #1 (Debian)) id 19vzja-0002nZ-00; Sun, 07 Sep 2003 15:37:42 +0200 To: Richard Zidlicky Cc: caml-list@inria.fr Subject: Re: [Caml-list] Native compiler support for m68k? References: <20030820104917.GB6782@linux-m68k.org> <20030820143238.A15392@pauillac.inria.fr> <20030905215803.GA1807@linux-m68k.org> From: David MENTRE Organization: none Date: Sun, 07 Sep 2003 15:37:42 +0200 In-Reply-To: <20030905215803.GA1807@linux-m68k.org> (Richard Zidlicky's message of "Fri, 5 Sep 2003 23:58:04 +0200") Message-ID: <878yp0vhw9.fsf@linux-france.org> User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 dmentre:01 malloc:01 bug:01 reuse:01 dmentre:01 libc:01 libc:01 compiler:01 ocaml:01 caml:01 behaviour:01 writes:01 mentre:01 mentre:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Richard Zidlicky writes: > What could be the source of such indeterministic behaviour? > gc? I would guess it is related to GC or bad memory allocation (in case of C code). As far as I remember, OCaml GC is using usual libc malloc and free, so you could activate libc checks to help find the bug (see mcheck(), there is also an environment variable I don't remember). You could also take a look at libefence. Other things that might help is to zeroing data structures before releasing them to free(). Sometimes, you reuse a datastructure that is has been freed. To make the port, what have you modified? Only Caml code or also C code? My .2 euros, Yours, d. -- David Mentré http://www.linux-france.org/~dmentre/david-mentre-public-key.asc GnuPG key fingerprint: A7CD 7357 3EC4 1163 745B 7FD3 FB3E AD7C 2A18 BE9E ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners