[Mono-winforms-list] Re: Error running monostub.exe.so afterfollowing directions

2a5gjx302@sneakemail.com 2a5gjx302@sneakemail.com
Sun, 27 Apr 2003 21:50:50 -0500


At 10:55 PM 27/04/2003 +0200, Alexandre Pigolkine wrote:
>On Sun, 2003-04-27 at 19:09, 2a5gjx302@sneakemail.com wrote:
>> 
>> Having thought about it in more depth, it seems as though the other GC
>> library is being used for GC calls from the main mono interpreter, while
>> the WINE GC library is being used only by monogc.c directly.
>> 
>> What now? :-)
>> 
>> Jonathan
>
>Lets try to start wine under debugger:
>
>$gdb wine
>(gdb)run monostub.exe.so
>
>on segfault you can see the backtrace by 'where' command.
>
>Alexandre

Here is the output. Sorry for the delay, went out during the evening. :-)

linsux:/c/mono# gdb wine
GNU gdb Red Hat Linux (5.2.1-4)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(gdb) set args monostub Test.exe
(gdb) run
Starting program: /usr/local/bin/wine monostub Test.exe
[New Thread 8192 (LWP 1535)]
parsing configuration file
initializing JIT engine
Initializing Boehm GC library...
GC_malloc start
GC_malloc end
.
.
.
GC_malloc start
GC_malloc end

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 8192 (LWP 1535)]
0x407056b5 in GC_find_limit (p=0x3c01377c "", up=0) at os_dep.c:647
647     os_dep.c: No such file or directory.
        in os_dep.c
(gdb) where
#0  0x407056b5 in GC_find_limit (p=0x3c01377c "", up=0) at os_dep.c:647
#1  0x40705500 in GC_init_linux_data_start () at os_dep.c:186
#2  0x40704759 in GC_init_inner () at misc.c:592
#3  0x407044f4 in GC_init () at misc.c:462
#4  0x406fe292 in GC_init_gcj_malloc (mp_index=5, mp=0x2) at gcj_mlc.c:60
#5  0x40660ca6 in mono_class_compute_gc_descriptor (class=0x3c060c68)
    at object.c:179
#6  0x40661130 in mono_class_vtable (domain=0x41322f78, class=0x3c060c68)
    at object.c:329
#7  0x406629b0 in mono_object_new (domain=0x41322f78, klass=0x3c060c68)
    at object.c:1131
#8  0x4067faeb in mono_runtime_init (domain=0x41322f78,
    start_cb=0x4064e7b4 <mono_thread_start_cb>,
    attach_cb=0x4064e870 <mono_thread_attach_cb>) at appdomain.c:69
#9  0x4064ec66 in mono_jit_init (file=0x40240721 "Test.exe") at jit.c:4267
#10 0x4057f1ef in WinMain (hInstance=0x2, hPrevInstance=0x0,
    lpszCmdLine=0x40240721 "Test.exe", nCmdShow=1) at monostub.c:122
#11 0x4057f095 in __wine_exe_main () at monostub.exe.spec.c:166
#12 0x4009c3af in start_process () at ../../scheduler/process.c:566
#13 0x400a010d in call_on_thread_stack (func=0x4009c190)
    at ../../scheduler/sysdeps.c:110
(gdb)

My (flimsy) understanding was that all GC calls should have been through
monogc.c since the regular GC is incompatible with WINE, and if that is the
case, then it is evidently the cause of the problem.

Jonathan