Wine & Boehm garbage collector

[François-Denis Gonthier]

Hello Wine-Devel

I have not filled a bug with this a some of you may already know a solution
to this problem.

I've a contributor to the Mono project (http://www.go-mono.com) working on
the System.Windows.Forms namespace.  It has been decided to use Wine to
implement this assembly since the S.W.F is rather tightly bound to the Win32
API.

But we are facing a nasty problem.  Current Mono implementation is using
Hans Boehm conservative garbage collector and Wine cannot seems to work
happily with that garbage collector.  The temporary solution for development
is to use Mono without garbage collection.  This solution however, should
not even be considered when Mono and it's System.Windows.Forms
implementation will go mainstream.

I've joined a small test case so one can try.  Wine just crash at the first
call to GC_malloc.  Any help or advice is appreciated.

François-Denis Gonthier

[Alexandre Julliard]

François-Denis Gonthier  writes:

François-Denis Gonthier  writes:
> boehm_crash.exe.so: boehm_crash.o boehm_crash.exe.spec.o boehm_crash.exe.dbg.o
>    gcc -shared -Wl,-Bsymbolic -D_REENTRANT -DWINELIB -o boehm_crash.exe.so \
>    boehm_crash.exe.spec.o \
>    boehm_crash.o boehm_crash.exe.dbg.o -lgc \
>    -lwine -lntdll.dll -lm -lpthread

You should remove -lntdll and -lpthread, it will probably help. If it
doesn't please post a gdb backtrace of the crash.

[François-Denis Gonthier]

-lntdll.dll and -lpthreads were left here from another makefile I've got.
I've removed them but it didn't help.  Here is the usual backtrace from gdb:

Starting program: /usr/local/bin/wine boehm_crash.exe.so
[New Thread 16384 (LWP 18946)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 18946)]
0x4048926a in GC_find_limit (p=0x805b77c "", up=0) at os_dep.c:647
647                     GC_noop1((word)(*result));
(gdb) bt
#0  0x4048926a in GC_find_limit (p=0x805b77c "", up=0) at os_dep.c:647
#1  0x40489087 in GC_init_linux_data_start () at os_dep.c:186
#2  0x40488394 in GC_init_inner () at misc.c:592
#3  0x404846d4 in GC_generic_malloc_inner (lb=100, k=1) at malloc.c:121
#4  0x4048482d in GC_generic_malloc (lb=100, k=1) at malloc.c:190
#5  0x40484ae4 in GC_malloc (lb=100) at malloc.c:309
#6  0x404720e4 in WinMain () at boehm_crash.c:5
#7  0x40472099 in __wine_exe_main () from
/home/neumann/monocvs/boehm_crash/boehm_crash.exe.so
#8  0x400bdfc0 in start_process () at ../../scheduler/process.c:564
#9  0x400c200d in call_on_thread_stack (func=0x400bdda4) at
../../scheduler/sysdeps.c:112

Apparently, the problem lies in Boehm GC, but before mailing Hans Boehm
about this (he can probably provide limited support only), I'd like to hear
about the people that knows about the internals of Wine.

----- Original Message -----
From: "Alexandre Julliard" 
To: "François-Denis Gonthier" 
Cc: 
Sent: Thursday, November 21, 2002 9:22 PM
Subject: Re: Wine & Boehm garbage collector

François-Denis Gonthier  writes:

François-Denis Gonthier  writes:
> boehm_crash.exe.so: boehm_crash.o boehm_crash.exe.spec.o

boehm_crash.exe.dbg.o
> gcc -shared -Wl,-Bsymbolic -D_REENTRANT -DWINELIB -o boehm_crash.exe.so \
> boehm_crash.exe.spec.o \
> boehm_crash.o boehm_crash.exe.dbg.o -lgc \
> -lwine -lntdll.dll -lm -lpthread

You should remove -lntdll and -lpthread, it will probably help. If it
doesn't please post a gdb backtrace of the crash.

--
Alexandre Julliard
[e-mail]

[Sylvain Petreolle]

Who could know better Wine internals than the author ? :)
> Apparently, the problem lies in Boehm GC, but before mailing Hans
> Boehm
> about this (he can probably provide limited support only), I'd like
> to hear
> about the people that knows about the internals of Wine.

___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

[Alexandre Julliard]

François-Denis Gonthier  writes:
> Apparently, the problem lies in Boehm GC, but before mailing Hans Boehm
> about this (he can probably provide limited support only), I'd like to hear
> about the people that knows about the internals of Wine.

It seems that seg fault is deliberate, it's trying to determine the
end of the addressable space. So if you continue execution the signal
should get handled; maybe this is what breaks, or maybe it's something
else later on.

[Vincent Béron]

Le jeu 21/11/2002 à 21:22, Alexandre Julliard a écrit :
> François-Denis Gonthier  writes:
> > Apparently, the problem lies in Boehm GC, but before mailing Hans

Boehm
> > about this (he can probably provide limited support only), I'd like

to hear
> > about the people that knows about the internals of Wine.
>
> It seems that seg fault is deliberate, it's trying to determine the
> end of the addressable space. So if you continue execution the signal
> should get handled; maybe this is what breaks, or maybe it's something
> else later on.

It's somewhere else:

Program received signal SIGSEGV, Segmentation fault.
0x405a54ab in GC_mark_from (mark_stack_top=0x80871b8,
mark_stack=0x80870a8,
    mark_stack_limit=0x808f0a8) at mark.c:647
647               deferred = *limit;
(gdb) bt
#0  0x405a54ab in GC_mark_from (mark_stack_top=0x80871b8,
    mark_stack=0x80870a8, mark_stack_limit=0x808f0a8) at mark.c:647
#1  0x405a51a0 in GC_mark_some (
    cold_gc_frame=0x40822cf8
"´\005\@\034-\202@h7[@(ÕY@´\005\@L-\202@@ÙY@(ÕY@h7[@L-\202@+ÙY@¯ÓZ@")
at mark.c:374
#2  0x4059dc46 in GC_stopped_mark (stop_func=0x4059d528
<GC_never_stop_func>)
    at alloc.c:500
#3  0x4059d940 in GC_try_to_collect_inner (
    stop_func=0x4059d528 <GC_never_stop_func>) at alloc.c:353
#4  0x405a7868 in GC_init_inner () at misc.c:703
#5  0x405a3b6d in GC_generic_malloc_inner (lb=100, k=1) at malloc.c:123
#6  0x405a3c9f in GC_generic_malloc (lb=100, k=1) at malloc.c:190
#7  0x405a3f51 in GC_malloc (lb=100) at malloc.c:295
#8  0x4021512b in WinMain () at boehm_crash.c:5
#9  0x402150a5 in __wine_exe_main () at boehm_crash.exe.spec.c:109
#10 0x400b1f5c in start_process () at ../../scheduler/process.c:564
#11 0x400b5ed5 in call_on_thread_stack (func=0x400b1d24)
    at ../../scheduler/sysdeps.c:112

I can't seem to find anything else for now, such as why limits gets too
high.

Vincent

[François-Denis Gonthier]

Thank you for all that information. I consider that any progress, even the
smallest one, is welcomed on that issue.  If needed, I'll forward that
information to a group that is more experience with Boehm's GC (GNU GJC
comes to my mind).

----- Original Message -----
From: "Vincent Béron" 
To: "François-Denis Gonthier" 
Cc: 
Sent: Friday, November 22, 2002 8:56 PM
Subject: Re: Wine & Boehm garbage collector

Le jeu 21/11/2002 à 21:22, Alexandre Julliard a écrit :
> François-Denis Gonthier  writes:
> > Apparently, the problem lies in Boehm GC, but before mailing Hans

Boehm
> > about this (he can probably provide limited support only), I'd like

to hear
> > about the people that knows about the internals of Wine.
>
> It seems that seg fault is deliberate, it's trying to determine the
> end of the addressable space. So if you continue execution the signal
> should get handled; maybe this is what breaks, or maybe it's something
> else later on.

It's somewhere else:

Program received signal SIGSEGV, Segmentation fault.
0x405a54ab in GC_mark_from (mark_stack_top=0x80871b8,
mark_stack=0x80870a8,
    mark_stack_limit=0x808f0a8) at mark.c:647
647               deferred = *limit;
(gdb) bt
#0  0x405a54ab in GC_mark_from (mark_stack_top=0x80871b8,
    mark_stack=0x80870a8, mark_stack_limit=0x808f0a8) at mark.c:647
#1  0x405a51a0 in GC_mark_some (
    cold_gc_frame=0x40822cf8
"´\005\@\034-\202@h7[@(ÕY@´\005\@L-\202@@ÙY@(ÕY@h7[@L-\202@+ÙY@¯ÓZ@")
at mark.c:374
#2  0x4059dc46 in GC_stopped_mark (stop_func=0x4059d528
<GC_never_stop_func>)
    at alloc.c:500
#3  0x4059d940 in GC_try_to_collect_inner (
    stop_func=0x4059d528 <GC_never_stop_func>) at alloc.c:353
#4  0x405a7868 in GC_init_inner () at misc.c:703
#5  0x405a3b6d in GC_generic_malloc_inner (lb=100, k=1) at malloc.c:123
#6  0x405a3c9f in GC_generic_malloc (lb=100, k=1) at malloc.c:190
#7  0x405a3f51 in GC_malloc (lb=100) at malloc.c:295
#8  0x4021512b in WinMain () at boehm_crash.c:5
#9  0x402150a5 in __wine_exe_main () at boehm_crash.exe.spec.c:109
#10 0x400b1f5c in start_process () at ../../scheduler/process.c:564
#11 0x400b5ed5 in call_on_thread_stack (func=0x400b1d24)
    at ../../scheduler/sysdeps.c:112

I can't seem to find anything else for now, such as why limits gets too
high.

Vincent