[Mono-list] strange mono initialization problem

[Paolo Molaro]

--NtwzykIc2mflq5ck
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On 08/21/02 John Sohn wrote:
> I have been experiencing the same problem while trying to use WineLib 
> with the Mono embedding API. The WineLib "application" is a shared
> library that gets invoked by the wine command so I believe it is the
> same problem as the one mentioned below. It looks like both of our
> projects are shared libraries that get called from another application.
> This code is in CVS under mcs/class/System.Windows.Forms/WINELib. 
> 
> I am using the embedding API to statically link the Mono JIT engine with
> this shared library. Dynamically linking the mono engine does not seem
> to work as conflicts appear to exist between the mono and wine
> libraries. For the last few days I had been getting the same results

Please, can you elaborate on what kind of conflicts?
Statically linking the mono engine is not a good idea, generally: the
only app that may do it is mono itself (for speed reasons: linking it
dynamically gets us a 5-10% slowdown).

> mentioned below. The application would hang on the mono_jit_init.
> However with the latest build from CVS the application now segfaults. If
> I disable garbage collection when building Mono the applications runs
> successfully. I had been using the Mono 0.13 snapshots successfully with
> garbage collection enabled so it seems a change occurred between the
> 0.13 and the 0.14 tag in CVS to cause this problem. I am using the

Something may have changed in the build setup, but nothing in the code
is related to this issue. Hans Boehm says it may actually be a bug in
the dynamic linker and he added a workaround in gc 6.1.

> latest version (6.1) of the garbage collection library. I am running

My tests (and others) say libgc 6.1 fixes the issue. Are you sure
you're using 6.1 and not an alpha release of it?
I tryed also linking my test case to libwine, but maybe I need to call
some function from it too, but with libgc 6.1 it works correctly.
If you can reproduce the issue starting from the simple test I'm attaching,
let me know so that we can investigate further.
Thanks.

lupus

-- 
-----------------------------------------------------------------
lupus@debian.org                                     debian/rules
lupus@ximian.com                             Monkeys do it better

--NtwzykIc2mflq5ck
Content-Type: text/x-csrc; charset=us-ascii
Content-Disposition: attachment; filename="main.c"

#include <dlfcn.h>
#include <stdio.h>

typedef void (*func)(void);
int main() {
	void *lib;
	func sym;

	lib = dlopen ("./gclib.so", RTLD_NOW);
	printf ("got lib: %p (%s)\n", lib, dlerror());
	sym = dlsym (lib, "do_stuff");
	printf ("got sym: %p (%s)\n", sym, dlerror());
	sym ();
	return 0;
}

--NtwzykIc2mflq5ck
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=makefile

#
# If you have unpacked gc6.1.tar.gz in this dir (and built it)
# run with:
# LD_LIBRARY_PATH=gc6.1/.libs/ ./main
# or with
# ./main
# you can build using 
# 	make NEWGC=
# to use the installed libgc

NEWGC=-L./gc6.1/.libs
all: gclib.so main

gclib.so: gclib.c makefile
	gcc -Wall -g -shared -o gclib.so gclib.c $(NEWGC) -lgc

# add -lgc to the following command line and it works
main: main.c makefile
	gcc -Wall -g -o main main.c -ldl

clean:
	-rm -f main gclib.so


--NtwzykIc2mflq5ck
Content-Type: text/x-csrc; charset=us-ascii
Content-Disposition: attachment; filename="gclib.c"

#include <gc/gc.h>
#include <stdio.h>

#define NUM 10000
#define SIZE 10000
void
do_stuff () {
	void *p;
	int i;
	printf ("in do_stuff()\n");
	for (i = 0; i < NUM; ++i)
		p = GC_malloc (SIZE);
}


--NtwzykIc2mflq5ck--