AW: [Caml-list] OCaml-3.08.1/MinGW: alloc_tuple fails

AW: [Caml-list] OCaml-3.08.1/MinGW: alloc_tuple fails

[Bauer, Christoph]

[-- Attachment #1: Type: text/plain, Size: 1561 bytes --]

> On Thu, Oct 14, 2004 at 04:59:01PM +0200, Bauer, Christoph wrote:
> > 
> > >  >   t = alloc_tuple( 100 );
> > >  >   for( i=0 ; i < 100; ++i )
> > >  >     Store_field( t, i, Int_val ( i ));
> > > 
> > > s/Int_val/Val_int/
> > 
> > 
> > Ok, that's correct. But the problem is before the for-loop.
> 
> It looks correct to me, but often memory corruption happens 
> earlier than is detected.  Try adding a call to Gc.full_major 
> () just before you call your C function.  If it crashes in 
> the Gc, then you've got memory corruption, and you'll need to 
> pepper your code with calls to Gc.full_major () to try and 
> narrow it down.

Ok, my example program is now:

(* test_it.ml *)
external test : unit -> unit = "test"

let _ =
  Gc.full_major ();
  test ()

Here is the gdb-output:

$ gdb ./test_it
GNU gdb 5.2.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-mingw32"...(no debugging symbols
found)...
(gdb) r
Starting program: c:\bauer\ocaml-mingw\test/./test_it.exe

Program received signal SIGSEGV, Segmentation fault.
0x00335e89 in ?? ()
(gdb) where
#0  0x00335e89 in ?? ()
#1  0x00335f8b in ?? ()
#2  0x10001234 in test (_=1) at test.cpp:10
#3  0x0040155b in camlTest_it__entry ()
#4  0x00402915 in main ()
(gdb)

regards,
Christoph Bauer

[-- Attachment #2: Type: text/html, Size: 3235 bytes --]

AW: [Caml-list] OCaml-3.08.1/MinGW: alloc_tuple fails

[Bauer, Christoph]

[-- Attachment #1: Type: text/plain, Size: 492 bytes --]

Hi,

> More generally speaking, given the way Windows DLLs work, I 
> don't think it is possible at all to put Caml-C stub code in 
> a DLL and pass that DLL to ocamlopt.  Static linking is your 
> friend here.

This solves my problem. The correct compile.sh is attached.

Thank you all for the answers!
Christoph Bauer


#!/bin/sh -v
gcc -mno-cygwin -c -O  -mms-bitfields -UCAML_DLL -I c:/ocamlmgw/lib test.c
-g
ar rcs libtest.a test.o
ocamlopt -o test_it.exe test_it.ml -cclib "-L. -ltest"

[-- Attachment #2: Type: text/html, Size: 1145 bytes --]

AW: [Caml-list] OCaml-3.08.1/MinGW: alloc_tuple fails

[Bauer, Christoph]

[-- Attachment #1: Type: text/plain, Size: 901 bytes --]

> On Oct 15, 2004, at 15:45, Olivier Andrieu wrote:
> 
> > Hum, doesn't alloc_tuple(n) (which is simply alloc(n, 0)) already 
> > initialise the block with zeroes ?
> 
> Oops, that's true, so it's OK to use Store_field.
> 
> I have another theory for Christoph's problem: maybe some 
> incompatibility between C and C++ calling conventions.  Is it 
> supposed to work when you compile a C file with a C++ 
> compiler, then link it with other C files compiled with a C compiler?

I tried both versions, the first one compiled and linked with gcc, the
second with g++. No success.

caml_tuple isn't used very often in the base library.



> 
> -- Damien
> 
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr Archives: 
http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ:
http://caml.inria.fr/FAQ/ Beginner's list:
http://groups.yahoo.com/group/ocaml_beginners

[-- Attachment #2: Type: text/html, Size: 2059 bytes --]

AW: [Caml-list] OCaml-3.08.1/MinGW: alloc_tuple fails

[Bauer, Christoph]

[-- Attachment #1: Type: text/plain, Size: 212 bytes --]


>  >   t = alloc_tuple( 100 );
>  >   for( i=0 ; i < 100; ++i )
>  >     Store_field( t, i, Int_val ( i ));
> 
> s/Int_val/Val_int/


Ok, that's correct. But the problem is before the for-loop.

Christoph Bauer

[-- Attachment #2: Type: text/html, Size: 791 bytes --]