GC with C issues

GC with C issues

[ronniec95]

Hello all,

I'm looking for some help with the following really short example when
I'm trying to reference a C allocated object from Caml (which works
fine), but the GC seems to not like it. Here's the sample code - pretty
short...


/* File: api.c */
typedef struct someObject_
{
	char* foo;
} someObject;

/*Allocate a new object*/
CAMLprim value api_newObject(value aString)
{
	CAMLparam1(aString);
	CAMLlocal1(retVal);
	someObject* x = (someObject*) malloc(1 * sizeof(someObject));
	x->foo = (char*) malloc(256 * sizeof(char));
	strcpy(x->foo, String_val(aString));
	retVal = alloc(1,Abstract_tag);
	Store_field(retVal,0,(value)x);
	fprintf(stderr,"New:%p\n",x);
	return retVal;
}
/* Print out the value */
CAMLprim value api_getValue(value inVal)
{
	CAMLparam1(inVal);
	someObject* x = NULL;
	
	x = (someObject*)Field(inVal,0);
	fprintf(stderr,"getValue called:%p",x);
	
	return copy_string(x->foo);
}
------
(* Ocaml test file main.ml *)
let _ =
    let x = Api.newObject "testString" (* New allocation everytime - leaks!*)
    in
    print_endline (Api.getValue x); (* This works fine *)
    Gc.full_major () (* This causes a segfault *)


I can't see what I'm doing wrong in the allocation? I expect this to
leak because I'm not freeing the allocated 'someObject' but I don't
expect it to segfault though?

Any help appreciated,

Ronnie

Re: [Caml-list] GC with C issues

[Daniel Bünzli]

When you use CAMLparam and CAMLlocal macros you must return from your C 
functions with CAMLreturn.

Also, beware of your use of strcpy with String_val(aString) according 
to the documention caml strings can contain embedded null characters.

Daniel

Re: [Caml-list] GC with C issues

[Olivier Andrieu]

 ronniec95@lineone.net [Thu, 3 Feb 2005]:
 > 
 > Hello all,
 > 
 > I'm looking for some help with the following really short example
 > when I'm trying to reference a C allocated object from Caml (which
 > works fine), but the GC seems to not like it. Here's the sample
 > code - pretty short...

<snip> 

 > I can't see what I'm doing wrong in the allocation? I expect this
 > to leak because I'm not freeing the allocated 'someObject' but I
 > don't expect it to segfault though?

When you use CAMLparam in a function you have to exit it with
CAMLreturn (or CAMLreturn0).

Do not use Store_field on your block: it's an Abstract block, not
traced by the GC, use the Field macro directly :

 Field (retVal, 0) = (value) x;


-- 
   Olivier

Re: [Caml-list] GC with C issues

[ronniec95]

Thank you, that did the trick.

Yeah I know about the strcpy issue....but I chose to ignore it in this
test program. In this particular case, the objective is to help me be
comfortable with callbacks and the GC which is not quite working as
yet...

Ronnie

On Thu, Feb 03, 2005 at 12:06:03PM +0100, Daniel B?nzli wrote:
> When you use CAMLparam and CAMLlocal macros you must return from your C 
> functions with CAMLreturn.
> 
> Also, beware of your use of strcpy with String_val(aString) according 
> to the documention caml strings can contain embedded null characters.
> 
> Daniel

Re: [Caml-list] GC with C issues

[ronniec95]

On Thu, Feb 03, 2005 at 12:16:43PM +0100, Olivier Andrieu wrote:
 
>  > I can't see what I'm doing wrong in the allocation? I expect this
>  > to leak because I'm not freeing the allocated 'someObject' but I
>  > don't expect it to segfault though?
> 
> When you use CAMLparam in a function you have to exit it with
> CAMLreturn (or CAMLreturn0).
> 
> Do not use Store_field on your block: it's an Abstract block, not
> traced by the GC, use the Field macro directly :
> 
>  Field (retVal, 0) = (value) x;

Hmm... I thought I was only supposed to do that when using
alloc_small/alloc_shr interface? However using your method does work in
this small example though I'm worried about if something unexpected will
happen in more 'real-life' code...

Regards

Ronnie
> 
> 
> -- 
>    Olivier

Re: [Caml-list] GC with C issues

[Olivier Andrieu]

 ronniec95@lineone.net [Thu, 3 Feb 2005]:
 > On Thu, Feb 03, 2005 at 12:16:43PM +0100, Olivier Andrieu wrote:
 >  
 > >  > I can't see what I'm doing wrong in the allocation? I expect
 > >  > this to leak because I'm not freeing the allocated
 > >  > 'someObject' but I don't expect it to segfault though?
 > > 
 > > When you use CAMLparam in a function you have to exit it with
 > > CAMLreturn (or CAMLreturn0).
 > > 
 > > Do not use Store_field on your block: it's an Abstract block, not
 > > traced by the GC, use the Field macro directly :
 > > 
 > >  Field (retVal, 0) = (value) x;
 > 
 > Hmm... I thought I was only supposed to do that when using
 > alloc_small/alloc_shr interface? However using your method does
 > work in this small example though I'm worried about if something
 > unexpected will happen in more 'real-life' code...

No, Store_field should only be used on structured blocks (check the
manual). You can access and modify abstract blocks directly since
their content is not examined by the GC. 

Your code works fine in this small example because the block initially
contains zeroes, but an abstract block can contain anything and this can
confuse the GC if you use Store_field.

-- 
   Olivier

Re: [Caml-list] GC with C issues

[Damien Doligez]

On Feb 3, 2005, at 12:31, ronniec95@lineone.net wrote:

>>  Field (retVal, 0) = (value) x;
>
> Hmm... I thought I was only supposed to do that when using
> alloc_small/alloc_shr interface? However using your method does work in
> this small example though I'm worried about if something unexpected 
> will
> happen in more 'real-life' code...

Since retVal has the "Abstract" tag, its contents is none of the GC's
business, so you don't need to use Store_field to tell it about
assignments.

On the other hand, depending on the bit-pattern of (the value of) x,
you might crash the GC if you use Store_field.  In this case, x is an
aligned pointer outside the heap, so you're safe either way.

But the proper way is to store directly with Field.

If you want to be pedantic, it's not really a field but a bunch of bytes
so the even more proper way is to write:

   * (someObject *) Bp_val (retVal) = x;

-- Damien