[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#600408: ocaml: Building OCaml with LOCAL_CALLBACK_BYTECODE enabled



Le Sunday 17 Oct 2010 à 00:10:41 (+0200), Stéphane Glondu a écrit :
> Le 16/10/2010 23:24, Guillaume Yziquel a écrit :
> > Package: ocaml
> > Version: 3.12.0-1~38
> > Severity: normal
> 
> Does this apply to 3.10.2 as well?

I guess so, but I haven't checked with 3.10.2.

> > I'm currently having issues with C++ callbacks to OCaml, [...]
> 
> Could you be more precise?

OCaml code calls C++ code, which then calls back OCaml code.

I register an OCaml array with caml_register_generational_global_root.
The array contains functions. The C++ code takes an offset in this array
and calls the function, typically with caml_callback3.

In native code, everything works fine. In bytecode, I've used gdb to
check what caml_interprete was doing while it crashes. The global array
callback_code gets populated with the OCaml bytecode ACC 6 APPLY ...
Using the ACC 6 instruction, I do get the good function to call back.
Now, when dereferencing (APPLY) this function to get the byte code of the
callback, it finds an opcode that is invalid. When you disassemble
caml_interprete, there is a 'jmpq *%rax' instruction. The interpreter
then jumps to an invalid opcode (supposed to be in %rax) and segfaults.

But it works fine in native code, so I'm not doing things completely
crazily. I'm currently trying to see why I have an invalid opcode there.

> > [...] and digging into
> > the callbacks.c file, I discovered that OCaml in Debian is not built
> > with the LOCAL_CALLBACK_BYTECODE macro enabled.
> 
> Why should it be?

To me, the question is "why shouldn't it be?".

I cannot pinpoint anything wrong yet with it, but I would much more
comfortable having local to the caml_callbackN_exn invocation.

Having it global makes me worry a lot about threads, callbacks, why am I
getting an invalid opcode, etc...

I'm not sure (and I do not believe) that it would solve my issue, but it
would just feel much more 'right' to me.

> > It seems to me that the current situation might be a can of worms and
> > segfaults, and I'm wondering whether it would not be a good idea to
> > build OCaml with LOCAL_CALLBACK_BYTECODE enabled.
> 
> Where did you get that from? Is this LOCAL_CALLBACK_BYTECODE documented
> somewhere? The only usage I see is in byterun/callback.c, and I don't
> see why it should matter here (we are just using the standard bytecode
> interpreter).

Haven't found documentation on LOCAL_CALLBACK_BYTECODE anywhere. I'm
stumbling on it doing painful gdb debugging.

I do not think that the comments in callbacks.c are very enlightening as
to the proper usage of LOCAL_CALLBACK_BYTECODE. I'm not saying that it
should be changed, but I do not see why it should be kept this way.

> Cheers,
> 
> -- 
> Stéphane

-- 
     Guillaume Yziquel
http://yziquel.homelinux.org



Reply to: