Re: [Caml-list] caml_oldify_local_roots crashes

Re: [Caml-list] caml_oldify_local_roots crashes

[Zakath]

> On Sun, Dec 26, 2004 at 04:35:53AM +0000, Jon Harrop wrote:
> > On Sat, 25 Dec 2004, haiku.issa wrote:
> > > Everything worked fine until I added a subfunction that simply
> > > merges two int lists.
> > I am no expert on this but I believe this implies that your interfacing 
> > between C and OCaml was already broken. Almost certainly something to do 
> > with the GC.

> It often helps to add lots of calls to Gc.full_major () to your code.
> One of these will crash, telling you that between that call and the
> previous one, you did something bad to the heap.
> 
> Rich.

I eventually found out : I was following the book "Devloppement d'applications avec Objective Caml" instead of the OCaml manual. They were advicing to register local variables and parameters (with CAMLparam* and CAMLlocal*) when using a callback.
Removing them made everything work fine.

To be more accurate, it was creating a corrupted entry of local_roots. from /asmrun/roots.c (or byterun), there was (lr->next == lr) in some point, which was causing the looping.
May be this should be said in the Manual ?

Thnaks for your help

Alexandre

caml_oldify_local_roots crashes

[haiku.issa]

Hi,

I am currently developping a small piece of software that uses
both OCaml and C (for openGL). The main loop is in C and I use
callback to call a Caml function that processes the key that
was pressed and returns the new state of a matrix.

Everything worked fine until I added a subfunction that simply
merges two int lists. The program then hanged each time a key
was pressed, without even executing the "print_string" I had
set everywhere. After hittinh ^C, gdb tells me that it was
currently executing caml_oldify_local_roots. Replacing the
merging function with 'fun () -> ()' solves the thing but I
need it.
I tried to rewrite it in an iterative way and it works fine
until it tries to make a minor GC (forcing it with Gc.minor()
makes it also hang).

Compiling in native code changed nothing, unfortunately, and
google found no useful advices...

I can post my code if necessary.

Thanks in advance for any help/insight

Accédez au courrier électronique de La Poste : www.laposte.net ; 
3615 LAPOSTENET (0,34€/mn) ; tél : 08 92 68 13 50 (0,34€/mn)

Re: [Caml-list] caml_oldify_local_roots crashes

[Jon Harrop]

On Sat, 25 Dec 2004, haiku.issa wrote:
> I am currently developping a small piece of software that uses
> both OCaml and C (for openGL). The main loop is in C and I use
> callback to call a Caml function that processes the key that
> was pressed and returns the new state of a matrix.

Do you have to use C at all? Have you looked at lablGL?

I strongly recommend that you avoid interfacing to C whenever possible...

> Everything worked fine until I added a subfunction that simply
> merges two int lists.

I am no expert on this but I believe this implies that your interfacing 
between C and OCaml was already broken. Almost certainly something to do 
with the GC. There are rules that you must adhere to when writing the 
interface code, of course, and human errors are a great cause of bugs 
here. I'd also strongly recommend that you try to write the simplest 
possible first working version and optimise it later only if necessary. 
Unfortunately I'm too drunk and full of turkey to help with any code right 
now...

Cheers,
Jon.

PS: If you program starts at "main" in C code then I assume you've 
initialised the OCaml GC before calling any OCaml code?

Re: [Caml-list] caml_oldify_local_roots crashes

[Richard Jones]

On Sun, Dec 26, 2004 at 04:35:53AM +0000, Jon Harrop wrote:
> On Sat, 25 Dec 2004, haiku.issa wrote:
> >Everything worked fine until I added a subfunction that simply
> >merges two int lists.
> I am no expert on this but I believe this implies that your interfacing 
> between C and OCaml was already broken. Almost certainly something to do 
> with the GC.

It often helps to add lots of calls to Gc.full_major () to your code.
One of these will crash, telling you that between that call and the
previous one, you did something bad to the heap.

Rich.