caml_startup/caml_cleanup

caml_startup/caml_cleanup

[Matthieu Dubuget]

Hello,

I have a problem related to memory allocated by caml_startup. (May
push toward a caml_cleanup function as proposed there for another
reason http://caml.inria.fr/mantis/view.php?id=385).

If you have any advice to help me solve this, please, send it to me!

Using OCaml I have written two DLLs (Windows). Let's call them A.dll
and B.dll.

I use them from LabVIEW (National Instrument). But that's not the key
point: see later.

LabVIEW automatically loads the libraries when I open a LabVIEW
program using them, and unload the libraries when the program is
closed. I can check that by adding a DllMain C function in my DLL,
with appropriate MessageBox.

With A.dll, I experience no problem at all, and it works fine.

B.dll also works fine. But under some conditions, AFTER B.dll has been
unloaded, LabVIEW crashes.

- Only if caml_startup was called (and also if this was the only
  function called from the library)

- I experience this with B.dll only. Not A.dll. I'm going to narrow
  the problem by removing functionnalities from B.dll step by
  step. But I would like to avoid this, because it will be long.

- If B.dll is produced with :
  * MSVC and OCAML MSVC 3.08.3, I just experience a crash
 
  * with  MSVC and OCAML MSVC 3.09.3,
    or    mingw gcc and ocaml mingw (3.09.3 or 3.08.3)

    I get a windows error:

    FRENCH: L'instruction à "0x....." emploie l'adresse mémoire
    "0x...". La mémoire ne peut être "read".

    APROXIMATIVE TRANSLATION: The instruction at "0x..." use memory
    address "0x...". The memory can not be read.

- Why did I said that LabVIEW is not the problem?

    - Because we reproduced the problem loading and unloadind B.dll in
      Java.

    - Because I experienced the problem another way: I did a little C
      program that load/unload B.DLL and exits. This program was run
      from an *eshell* emacs session. And after that. I experienced
      the window error box when calling another program (It was
      omake).

Thanks in advance for any help.

Salutations.

Matt
 

Re: [Caml-list] caml_startup/caml_cleanup : problem with threads

[Matthieu Dubuget]

Matthieu Dubuget a écrit :
> - I experience this with B.dll only. Not A.dll. I'm going to narrow
>   the problem by removing functionnalities from B.dll step by
>   step. 
>
>   
OK. I have the problem as soon as my DLL uses Thread module.

What does caml_startup in this case?

Here is a minimal set of files allowing to produce a problematic DLL.
Do you think there is any problem with this code and the compilation
command lines?

demo.ml
---------------
|Callback.register "wait a moment" Thread.delay
---------------

bug_demo_st.c
---------------
|#include <caml/mlvalues.h>
|#include <caml/callback.h>
|
|static int demo_init_done = 0;
|
|void demo_init (){
|  char * argv[] = { "argv", NULL};
|
|  if (!demo_init_done) {
|    caml_startup (argv);
|    demo_init_done = 1;
|  }
|}
|
|int demo_init_ok (void){  return demo_init_done; }
---------------

bug_demo.def:
---------------
|EXPORTS
|demo_init
|demo_init_ok
---------------

And the compilations instructions I used (MinGW version)
---------------
|gcc -mno-cygwin -O -mms-bitfields -c -I"C:\Program Files\Objective
Caml\lib" "bug_demo_st.c"   
|     or simply:  ocamlopt -c bug_demo_st.c
|ocamlopt.opt -thread -output-obj -o demog.o unix.cmxa threads.cmxa demo.ml
|gcc -mno-cygwin -Wl,--kill-at -shared -o bug_demo.dll -L"C:\Program
Files\Objective Caml\lib" \
|             demog.o  bug_demo_st.o bug_demo.def  -lunix -lasmrun
-lwsock32 -lthreadsnat -lthreads
---------------

> - Why did I said that LabVIEW is not the problem?
>
>     - Because we reproduced the problem loading and unloadind B.dll in
>       Java.
>
>     - Because I experienced the problem another way: I did a little C
>       program that load/unload B.DLL and exits. This program was run
>       from an *eshell* emacs session. And after that. I experienced
>       the window error box 
randomly
> when calling another program (It was
>       omake).
>   
I was not able to produce any simple test program demonstrating the DLL
unloading problem (yet).

Do you think I should fill a bug report or am I wrong somewhere?

Salutations

Matt