Working with GDI+
Having to port System.Windows.Forms and System.Drawing to Linux, I would like to know how GDI+ works under Wine and WineLib? Anyone tried?
Re: Wine & Boehm garbage collector
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" <[EMAIL PROTECTED]> To: "François-Denis Gonthier" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 ) at alloc.c:500 #3 0x4059d940 in GC_try_to_collect_inner ( stop_func=0x4059d528 ) 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
Re: Wine & Boehm garbage collector
-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" <[EMAIL PROTECTED]> To: "François-Denis Gonthier" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, November 21, 2002 9:22 PM Subject: Re: Wine & Boehm garbage collector François-Denis Gonthier <[EMAIL PROTECTED]> writes: François-Denis Gonthier <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
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
makefile
Description: Binary data
#include
int WinMain (void)
{
GC_malloc(100);
}
