Re: Interfaçage C/CAML

Re: Interfaçage C/CAML

[David McClain]

Many thanks for pointing this error out... I had inadvertantly used the
incorrect Store_... form twice on finalized structures in my bulk of code,
although I have never experienced any problems from it... But just to be
safe I read the message in the archives and went through by stuff to clean
it up...

- David

-----Original Message-----
From: David Mentré <David.Mentre@irisa.fr>
To: Markus Mottl <mottl@miss.wu-wien.ac.at>
Cc: Nicolas Joliot <Nicolas.Joliot@irisa.fr>; caml-list@inria.fr
<caml-list@inria.fr>
Date: Monday, August 14, 2000 9:49 AM
Subject: Re: Interfaçage C/CAML


>Markus Mottl <mottl@miss.wu-wien.ac.at> writes:
>
>> It seems that a common bug has struck again: using "Store_{whatever}" in
>> C-interfaces is only allowed (and then mandatory) with structured blocks.
>> Using it for anything else may crash the GC.
>
>I would say that Store_{whatever} macros are useful for data structures
>that are created in the C-world but should be managed (and destroyed) in
>the OCaml-world, WITHOUT any further access on the data by the C
>part. For all other cases, use the Field_{whatever} macros. With this
>macro, the OCaml GC won't try to have a look at your C data structures.
>
>By the way, Markus has already found a bug like this in my own code. See
>this message for further details on how the bug is triggered :
>  http://caml.inria.fr/archives/200002/msg00074.html
>
>I hope it helps,
>d.
>--
> David.Mentre@irisa.fr -- http://www.irisa.fr/prive/dmentre/
> Opinions expressed here are only mine.
>

Re: Interfaçage C/CAML

[Markus Mottl]

On Fri, 11 Aug 2000, Xavier Leroy wrote:
> > It seems that a common bug has struck again: using "Store_{whatever}" in
> > C-interfaces is only allowed (and then mandatory) with structured blocks.
> > Using it for anything else may crash the GC.
> 
> No, no, no!  Store_field can only be used (and is mandatory) for
> structured blocks (with tag < No_scan_tag), but Store_double_field
> can be used (and is mandatory) for blocks with tag Double_array_tag.

Uff, yes, indeed, my explanation of "Store_{whatever}" was actually
correct, but I forgot about the specific treatment of double arrays (or
more precisely: values with the "Double_array_tag"), which are unboxed and
therefore do not fall under the rules for structured blocks.

Sorry for the confusion! Since I had seen problems with "Store_{...}"
already three times, I didn't think further about the special case...

Best regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl

Re: Interfaçage C/CAML

[David Mentré]

Markus Mottl <mottl@miss.wu-wien.ac.at> writes:

> It seems that a common bug has struck again: using "Store_{whatever}" in
> C-interfaces is only allowed (and then mandatory) with structured blocks.
> Using it for anything else may crash the GC.

I would say that Store_{whatever} macros are useful for data structures
that are created in the C-world but should be managed (and destroyed) in
the OCaml-world, WITHOUT any further access on the data by the C
part. For all other cases, use the Field_{whatever} macros. With this
macro, the OCaml GC won't try to have a look at your C data structures.

By the way, Markus has already found a bug like this in my own code. See
this message for further details on how the bug is triggered :
  http://caml.inria.fr/archives/200002/msg00074.html

I hope it helps,
d.
-- 
 David.Mentre@irisa.fr -- http://www.irisa.fr/prive/dmentre/
 Opinions expressed here are only mine.

Re: Interfaçage C/CAML

[Xavier Leroy]

> [French>
>
> Si je le comprends bien, le problem c'est l'utilisation du
> "Store_double_field". La solution dans ce cas serait d'essayer le macro
> "Double_field" en place de l'autre macro.
> 
> C'est souvant un source des erreurs - peut-etre on pourrait changer le nom
> de "Store_double_field"? Il me semble que la plupart des programmeurs
> soient confuses par "Store"...
> 
> "Store_..." ne doit etre utilise que avec des "blocs structures", ou il
> sont obligatoirs.

> [English]
> 
> It seems that a common bug has struck again: using "Store_{whatever}" in
> C-interfaces is only allowed (and then mandatory) with structured blocks.
> Using it for anything else may crash the GC.

No, no, no!  Store_field can only be used (and is mandatory) for
structured blocks (with tag < No_scan_tag), but Store_double_field
can be used (and is mandatory) for blocks with tag Double_array_tag.

(If you do Double_field(array, n) = d, you'll run into alignment
problems on some platforms, e.g. the Sparc and Mips.)

So, Nicolas's code seems correct in this respect.

Nicolas: could you please send to caml@inria.fr (and not to caml-list)
a complete program that reproduces the crash?  There's not enough
details in your message to understand what goes wrong.

- Xavier Leroy

Re: Interfaçage C/CAML

[Markus Mottl]

[Francais] (Excusez-moi mon francais faible)

On Thu, 10 Aug 2000, Nicolas Joliot wrote:
> Lorsqu'elles sont appelées séparément, je peux afficher les resulats
> sans problème, mais lorsque les deux sont appelées successivement et que
> j'essaye d'afficher le tableau de floatants, j'ai systématiquement un
> "Bus Error".

Je ne suis pas sur, mais ca peut-etre un problem entre l'interface de C et
le GC...

> - déclaration : CAMLlocal1(tableau_float)
> - allocation : tableau_float=alloc(nb_element*2,Double_array_tag)
> - Utilisation :Store_double_field(tableau_float,i,floatant_a_renvoyer)
> _ retour sous CAML par CAMLreturn

Si je le comprends bien, le problem c'est l'utilisation du
"Store_double_field". La solution dans ce cas serait d'essayer le macro
"Double_field" en place de l'autre macro.

C'est souvant un source des erreurs - peut-etre on pourrait changer le nom
de "Store_double_field"? Il me semble que la plupart des programmeurs
soient confuses par "Store"...

"Store_..." ne doit etre utilise que avec des "blocs structures", ou il
sont obligatoirs.

Amicalement,
Markus Mottl

---------------------------------------------------------------------------

[English]

It seems that a common bug has struck again: using "Store_{whatever}" in
C-interfaces is only allowed (and then mandatory) with structured blocks.
Using it for anything else may crash the GC.

Maybe we could change the names of the "Store_..."-macros so that people
don't mistakenly believe that these are generally the right ones to "store"
values?  Something like "Store_Block_..." or similar (less verbose)?

Best regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl

Interfaçage C/CAML

[Nicolas Joliot]

Je suis actuellement en train de travailler sur l'interfaçage pour CAML
de la bibliothèque ILOG CPLEX 6.5.

J'ai actuellement des problèmes lorsque j'invoque 2 de ces fonctions C
sous Caml, l'une me renvoyant un floatant, l'autre un tableau de
floatant.

Lorsqu'elles sont appelées séparément, je peux afficher les resulats
sans problème, mais lorsque les deux sont appelées successivement et que
j'essaye d'afficher le tableau de floatants, j'ai systématiquement un
"Bus Error".

Par contre, l'affichage du floatant simple ne pose pas de problème,
aussi je pense que l'erreur doit provenir de la façon dont j'ai
représenté le tableau de floatant dans le fichier interface .c :

- déclaration : CAMLlocal1(tableau_float)
- allocation : tableau_float=alloc(nb_element*2,Double_array_tag)
- Utilisation :Store_double_field(tableau_float,i,floatant_a_renvoyer)
_ retour sous CAML par CAMLreturn

La représentation de ce tableau de float de type value est-elle
correcte? Si oui, quel peut être l'explication de ce plantage
systématique? Si non, quel est la bonne représentation en type "value"
d'un tableau de floatant? ( qui est d'ailleurs assez mal expliquée sur
le manuel on-line de ocaml)

Par ailleurs, j'ai remarqué qu'un printf"%f" pour afficher les floatants
de ce tableau engendrait parfois un "Bus Error".


-----------------------------------------------------------
JOLIOT Nicolas.
IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France
Tél: +33 (0) 2 99 84 71 00, Fax: +33 (0) 2 99 84 71 71
email : nicolas.joliot@irisa.fr
-----------------------------------------------------------