Wine & Boehm garbage collector
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
François-Denis Gonthier <fgonthier(a)hermes.usherb.ca> writes: François-Denis Gonthier <fgonthier(a)hermes.usherb.ca> 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 julliard(a)winehq.com
-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" <julliard(a)winehq.com> To: "François-Denis Gonthier" <fgonthier(a)hermes.usherb.ca> Cc: <wine-devel(a)winehq.com> Sent: Thursday, November 21, 2002 9:22 PM Subject: Re: Wine & Boehm garbage collector François-Denis Gonthier <fgonthier(a)hermes.usherb.ca> writes: François-Denis Gonthier <fgonthier(a)hermes.usherb.ca> 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 julliard(a)winehq.com
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
François-Denis Gonthier <fgonthier(a)hermes.usherb.ca> 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. -- Alexandre Julliard julliard(a)winehq.com
Le jeu 21/11/2002 à 21:22, Alexandre Julliard a écrit :
François-Denis Gonthier <fgonthier(a)hermes.usherb.ca> 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(a)h7[@(ÕY@´\005\\@L-\202@@ÙY@(ÕY(a)h7[@L-\202(a)+Ù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
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" <vberon(a)mecano.gme.usherb.ca> To: "François-Denis Gonthier" <fgonthier(a)hermes.usherb.ca> Cc: <wine-devel(a)winehq.com> 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 <fgonthier(a)hermes.usherb.ca> 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(a)h7[@(ÕY@´\005\\@L-\202@@ÙY@(ÕY(a)h7[@L-\202(a)+Ù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
participants (4)
-
Alexandre Julliard -
François-Denis Gonthier -
Sylvain Petreolle -
Vincent Béron