[Caml-list] Garbage collector woes

[Caml-list] Garbage collector woes

[Christoph Höger]

Dear all,

I have a program using OCaml callbacks, one of these callbacks looks is
the following:

/* Callbacks */
CAMLprim iconv(void* user_data, double t, double const *x, double *cond) {
  CAMLparam0();
  CAMLlocal3(ml_t, ml_x, ml_cond);
  const value desc = *((value*)user_data);

  /* Wrap the values in fresh big arrays */
  ml_t = caml_copy_double(t);
  ml_x = caml_ba_alloc_dims(CAML_BA_FLOAT64 | CAML_BA_C_LAYOUT, 1,
(double*)x, Int_val(N(desc)));
  ml_cond = caml_ba_alloc_dims(CAML_BA_FLOAT64 | CAML_BA_C_LAYOUT, 1,
cond, Int_val(MFIT(desc)));

  /* call the OCaml callback */
  caml_callback3(ICONV(desc), ml_t, ml_x, ml_cond);
  CAMLreturn0;
}

all arguments are allocated directly in C-code, user-data is a
registered global root. I am running 4.02.3 .

However at some point in my example, the x and cond arguments are
overwritten on the stack, resulting in a segmentation fault in the ocaml
callback.

Is it possible that the GC overwrites values in this stackframe, even
though the function is announced via CAMLparam0 ? How do I write
C-functions that call back into OCaml then?

thanks alot,

Christoph
-- 
Christoph Höger

Technische Universität Berlin
Fakultät IV - Elektrotechnik und Informatik
Übersetzerbau und Programmiersprachen

Sekr. TEL12-2, Ernst-Reuter-Platz 7, 10587 Berlin

Tel.: +49 (30) 314-24890
E-Mail: christoph.hoeger@tu-berlin.de

Re: [Caml-list] Garbage collector woes

[Jeremy Yallop]

On 4 July 2016 at 17:04, Christoph Höger <christoph.hoeger@tu-berlin.de> wrote:
> I have a program using OCaml callbacks, one of these callbacks looks is
> the following:
>
> /* Callbacks */
> CAMLprim iconv(void* user_data, double t, double const *x, double *cond) {
>   CAMLparam0();
>   CAMLlocal3(ml_t, ml_x, ml_cond);
>   const value desc = *((value*)user_data);

I'm guessing that 'desc' points to a block and N, MFIT and ICONV are
field accessors.

If so, you need to register 'desc' as a root here, since
caml_copy_double or caml_ba_alloc_dims could trigger a gc, moving desc
before it's next used.

It's probably also better not to call your exported function 'iconv',
since there's a POSIX function of that name.

>   /* Wrap the values in fresh big arrays */
>   ml_t = caml_copy_double(t);
>   ml_x = caml_ba_alloc_dims(CAML_BA_FLOAT64 | CAML_BA_C_LAYOUT, 1,
> (double*)x, Int_val(N(desc)));
>   ml_cond = caml_ba_alloc_dims(CAML_BA_FLOAT64 | CAML_BA_C_LAYOUT, 1,
> cond, Int_val(MFIT(desc)));
>
>   /* call the OCaml callback */
>   caml_callback3(ICONV(desc), ml_t, ml_x, ml_cond);
>   CAMLreturn0;
> }

Re: [Caml-list] Garbage collector woes

[Christoph Höger]

Am 04.07.2016 um 18:21 schrieb Jeremy Yallop:
> I'm guessing that 'desc' points to a block and N, MFIT and ICONV are
> field accessors.

That is correct. N, MFIT and ICONV are macros defined as Field(.., ..).

> If so, you need to register 'desc' as a root here, since
> caml_copy_double or caml_ba_alloc_dims could trigger a gc, moving desc
> before it's next used.

By registering as a root you mean to also declare it via CAMLlocal? Is
this necessary/appropriate, since &desc is already a registered global root.

Do you have any clue how that moving of desc could trigger the
overwriting of x and cond?

> It's probably also better not to call your exported function 'iconv',
> since there's a POSIX function of that name.

Good to know. I am merely implementing an API here, so these names
aren't mine ;).

-- 
Christoph Höger

Technische Universität Berlin
Fakultät IV - Elektrotechnik und Informatik
Übersetzerbau und Programmiersprachen

Sekr. TEL12-2, Ernst-Reuter-Platz 7, 10587 Berlin

Tel.: +49 (30) 314-24890
E-Mail: christoph.hoeger@tu-berlin.de

Re: [Caml-list] Garbage collector woes

[Jeremy Yallop]

On 4 July 2016 at 18:06, Christoph Höger <christoph.hoeger@tu-berlin.de> wrote:
> Am 04.07.2016 um 18:21 schrieb Jeremy Yallop:
>> I'm guessing that 'desc' points to a block and N, MFIT and ICONV are
>> field accessors.
>
> That is correct. N, MFIT and ICONV are macros defined as Field(.., ..).
>
>> If so, you need to register 'desc' as a root here, since
>> caml_copy_double or caml_ba_alloc_dims could trigger a gc, moving desc
>> before it's next used.
>
> By registering as a root you mean to also declare it via CAMLlocal?

Yes, that's a reasonable way to do it.

> Is this necessary/appropriate, since &desc is already a registered global root.

In fact, &desc is not a registered global root, since desc is a local
variable, with its own fresh address.  It's user_data that's a global
root, and desc is simply a copy of the contents of user_data.  So when
the GC updates *user_data, desc is left unchanged.

> Do you have any clue how that moving of desc could trigger the
> overwriting of x and cond?

If the GC replaces the value that desc points to with some other value
that's then invoked as a callback, pretty much anything can happen.
(Of course, it's also possible that the problem lies somewhere else
entirely.)