[Mono-list] strange mono initialization problem

[John Sohn]

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
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
latest version (6.1) of the garbage collection library. I am running
RedHat 7.3 with (RPM version) glibc-2.2.5-39. 

Even though the application now segfaults the backtrace still appears
similar. Here's the backtrace from gdb: 

#0  0x40609efe in GC_find_limit (p=0x804d728 "", up=0) at os_dep.c:647 
#1  0x40609d34 in GC_init_linux_data_start () at os_dep.c:186 
#2  0x406090ee in GC_init_inner () at misc.c:592 
#3  0x40605a89 in GC_generic_malloc_inner (lb=28, k=1) at malloc.c:121 
#4  0x40605bbe in GC_generic_malloc (lb=28, k=1) at malloc.c:190 
#5  0x40605d57 in GC_malloc (lb=28) at malloc.c:295 
#6  0x40505e49 in mono_g_hash_table_new_full ( 
    hash_func=0x405be75c <g_direct_hash>, 
    key_equal_func=0x405be764 <g_direct_equal>, key_destroy_func=0, 
    value_destroy_func=0) at mono-hash.c:154 
#7  0x40505e1e in mono_g_hash_table_new (hash_func=0x405be75c
<g_direct_hash>, 
    key_equal_func=0x405be764 <g_direct_equal>) at mono-hash.c:124 
#8  0x4050501f in TlsSetValue (idx=0, value=0x807ecf0) at threads.c:672 
#9  0x404b9f33 in mono_thread_start_cb (stack_start=0xffffffff) at
jit.c:4059 
#10 0x404ba1c7 in mono_jit_init (file=0x40350168 "NativeWindowTest.exe")
    at jit.c:4139 

On Thu, 2002-08-15 at 13:59, Joseph Wenninger wrote: 
> Hi
> 
> >
> > The only limitation I know of is with the pthread library: to be able to
> > dlopen a shared object that uses pthread (and have it work), your main
> > application needs to be linked to libpthread as well. Is that already
> > the case?
> 
> Yes, it is already linked against libpthread
> 
> > Of course a stack trace is always useful to check where the real problem
> > is.
> 
> I tried that, but I couldn't get any usefull symbols displayed in gdb.
> 
> >
> > lupus
> 
> 
> I've narrowed the problem down a littlebit, it happens in io-layer/thread.c:
> 
> g_print("TlsSetValue: 9\n");
> 
> #if HAVE_BOEHM_GC
>         if (!tls_gc_hash)
>                 tls_gc_hash = mono_g_hash_table_new(g_direct_hash, 
> g_direct_equal);
>         g_print("TlsSetValue: 9a\n");
> 
>         mono_g_hash_table_insert (tls_gc_hash, MAKE_GC_ID (idx), value);
> #endif
>         g_print("TlsSetValue: 10\n");
> 
> the output line for 9a, is never reached.
> 
> Kind regards
> Joseph Wenninger
> 
> PS: I'm using Suse 8.0
> 
> 
> 
> 
> _______________________________________________
> Mono-list maillist  -  Mono-list@ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list