Last updated on 09/01/08 07:29:15 (2 years ago)

dev-lang/mono-2.x rev 1

Maintainer(s): andreasf Haiku status: broken
BONE status: untested
R5 status: broken

dev-lang/mono/2.x/1

Mono will not easily run on BeOS, it requires pthreads among other things.

Getting Mono

Either checkout mono and mcs from SVN ( http://www.mono-project.com/AnonSVN) and apply patches, or use my  "haiku" Git branch of mono with mcs from SVN or Git.

Something like this (cf.  http://www.mono-project.com/GitSVN): 

mkdir mono
cd mono
git init
git remote add afaerber git://repo.or.cz/mono/afaerber.git
git checkout --track -b haiku afaerber/haiku
cd ..
svn co svn://anonsvn.mono-project.com/source/trunk/mcs

Building Mono

To do a VPATH build, run (from the mono dir) 

NOCONFIGURE=1 ./autogen.sh
(cd eglib; NOCONFIGURE=1 ./autogen.sh

followed by (from your chosen build dir) 

path/to/configure --prefix=/boot/home/config --with-glib=embedded --with-gc=none --with-ikvm-native=no \
 --enable-maintainer-mode --enable-compile-warnings \
 CPPFLAGS=-I/boot/home/config/include LDFLAGS=-L/boot/home/config/lib
make

This avoids pulling in the full GLib dependency but needs libiconv installed (cf. CPPFLAGS, LDFLAGS) (or will later fail to link). It also disables the Garbage Collector to rule that out as source of errors. Support for Java (IKVM) is only disabled to speed up the build.

Progress

autogen.sh fails on Haiku, not finding libtool for some reason ( Ticket); use LIBTOOL=/boot/home/config/bin/libtool ./autogen.sh as workaround. (fixed in Haiku r25190)

Old patch

Building with eglib fails...

  • due to unresolved iconv symbols. Using libiconv works around this.
  • in mono/utils/mono-io-compatibility.c reporting a parse error for size_t len. Moving the declaration to the start of the block fixes it. Fixed in Mono r109505.
  • in mono/utils/mono-mmap.c due to madvise et al. Use fallback instead of HAVE_MMAP implementation. Haiku has mprotect now but posix_madvise, use that instead.
  • in mono/io-layer/collection.c due to undefined PTHREAD_STACK_MIN ( Ticket). Using 65536 instead, like on *BSD.
  • in mono/io-layer/error.c due to undefined ESOCKTNOSUPPORT. Making the case conditional.
  • in mono/io-layer/processes.c due to missing include file sched.h ( Ticket). Warning about implicit declaration of function makedev. Define it as workaround. (sched.h was added and sched_yield implemented in Haiku r26820)
  • in mono/io-layer/threads.c due to sched.h.
  • linking monoburg with eglib due to a general known Mono  bug. Apply slightly adjusted patch.
  • in mono/metadata/socket-io.c due to undefined AF_SNA, AF_DECnet etc. Make them conditional, and undefine AF_INET6 like on Windows.
  • linking pedump due to mprotect in mono/metadata/rawbuffer.c (implemented in Haiku), sched_yield in threads.c ( Ticket), getprotobyname, socket, __inet_addr etc. in socket-io.c, rand.c, io-layer/sockets.c. Stub some code out and link with libnetwork.
  • in mono/mini/exceptions-x86.h due to dereferencing pointer to incomplete type in mono_arch_sigctx_to_monoctx, not using MONO_ARCH_USE_SIGACTION. Defining it in mini-x86.h leads to other errors. The problem appears to be that neither struct sigcontext nor ucontext_t are defined... Trying to use MONO_ARCH_USE_SIGACTION with BeOS-compatible vregs instead (cf. signal.h). EBX is currently not retrievable ( Ticket). (EBX/EBP fixed in Haiku r26818)
  • linking mono due to an undefined reference to __signbitf in mono/mini/mini-x86.c. This appears to be caused by the mono_signbit macros from mono/utils/mono-math.h. Undefine HAVE_SIGNBIT. Appears to be a problem with Haiku's signbit macro definition in math.h ( Ticket). (fixed in Haiku r27259)
  • in support/map.c due to missing st_blocks member in struct stat, and undefined S_ISTXT. Haiku's ALLPERMS seems wrong ( Ticket). (ALLPERMS fixed in Haiku r26761)
  • in support/macros.c due to st_blocks.
  • in support/old-map.c due to undefined SIGIO.
  • in support/serial.c due to undefined TIOCOUTQ and TIOCM*. That is most likely for the System.IO.* implementation (class library support) and can be ignored.

Building then succeeds, but execution of mcs hangs: 

(gdb) bt
#0  0xffff0102 in ?? ()
#1  0x006985d4 in semop () from /boot/beos/system/lib/libroot.so
#2  0x0033cd54 in shm_sem_lock (sem=27)
    at /ToBe/Mono/mono/mono/io-layer/shared.c:530
#3  0x0033cff6 in _wapi_shm_sem_lock (sem=2147408852)
    at /ToBe/Mono/mono/mono/io-layer/shared.c:721
#4  0x0033cb60 in shm_semaphores_init ()
    at /ToBe/Mono/mono/mono/io-layer/shared.c:435
#5  0x0033cf8c in _wapi_shm_semaphores_init ()
    at /ToBe/Mono/mono/mono/io-layer/shared.c:703
#6  0x003194e5 in shared_init () at /ToBe/Mono/mono/mono/io-layer/handles.c:233
#7  0x003355fb in mono_once (once=0x4dd974, once_init=0x319490 <shared_init>)
    at /ToBe/Mono/mono/mono/io-layer/mono-mutex.c:80
#8  0x00319a9b in _wapi_handle_new (type=WAPI_HANDLE_SEM, 
    handle_specific=0x7ffedd4c) at /ToBe/Mono/mono/mono/io-layer/handles.c:413
#9  0x0033aff3 in sem_create (security=0x0, initial=0, max=2147483647)
    at /ToBe/Mono/mono/mono/io-layer/semaphores.c:181
#10 0x0033b81e in CreateSemaphore (security=0x0, initial=0, max=2147483647, 
    name=0x0) at /ToBe/Mono/mono/mono/io-layer/semaphores.c:353
#11 0x002ff6b0 in mono_thread_pool_init ()
    at /ToBe/Mono/mono/mono/metadata/threadpool.c:989
#12 0x00277455 in mono_runtime_init (domain=0x1801a230, 
    start_cb=0x391cdc <mono_thread_start_cb>, 
    attach_cb=0x391d68 <mono_thread_attach_cb>)
---Type <return> to continue, or q <return> to quit---
    at /ToBe/Mono/mono/mono/metadata/appdomain.c:142
#13 0x003998db in mini_init (filename=0x4a43fe "object int", 
    runtime_version=0x4a40e6 "ulong double")
    at /ToBe/Mono/mono/mono/mini/mini.c:15335
#14 0x0022e729 in mono_main (argc=6, argv=0x7ffee538)
    at /ToBe/Mono/mono/mono/mini/driver.c:1427
#15 0x0022c9b7 in main (argc=2147408852, argv=0x1b)
    at /ToBe/Mono/mono/mono/mini/main.c:30

Looks like a problem with XSI semaphores in Mono's implementation of Win32 API (WAPI) shared handles.

Disabling shared handles (--disable-shared-handles), I get the following crash: 

Thread 102273 caused an exception: General protection fault
[...]
[Switching to team /boot/home/mono/mono/mini/mono --config /boot/home/mono/runtime (102273) thread mono (102273)]
0x7ffebc44 in ?? ()
(gdb) bt
#0  0x7ffebc44 in ?? ()
#1  0x00000000 in ?? ()
#2  0x7ffebc50 in ?? ()
#3  0xb80cc483 in ?? ()
#4  0x00000035 in ?? ()
#5  0x7ffedb6c in ?? ()
#6  0x24548d00 in ?? ()
#7  0xc363cd04 in ?? ()
#8  0x180648e1 in ?? ()
#9  0x00210216 in ?? ()
#10 0x00000001 in ?? ()
#11 0x189bddf8 in ?? ()
#12 0x7ffec0a4 in ?? ()
#13 0x967b7fdc in ?? ()
#14 0x90b7e258 in ?? ()
#15 0x7ffebeac in ?? ()
#16 0xffff027f in ?? ()
#17 0xffff0020 in ?? ()
#18 0xffffffff in ?? ()
#19 0x180648de in ?? ()
#20 0x072b001b in ?? ()
#21 0x7ffebeac in ?? ()
#22 0xffff0023 in ?? ()
#23 0xe3f07a0a in ?? ()
---Type <return> to continue, or q <return> to quit---
#24 0x00000000 in ?? ()
#25 0x6770ffff in ?? ()
#26 0x0000d7f9 in ?? ()
#27 0xffff0000 in ?? ()
#28 0x00001003 in ?? ()
#29 0x00000000 in ?? ()
#30 0x69ccffff in ?? ()
#31 0x0000e3f0 in ?? ()
#32 0xffff0000 in ?? ()
#33 0xe3f06a44 in ?? ()
#34 0x00000000 in ?? ()
#35 0x0000ffff in ?? ()
#36 0x00000000 in ?? ()
#37 0x3fff8000 in ?? ()
#38 0x00000000 in ?? ()
#39 0xfffffffe in ?? ()
#40 0xa800401d in ?? ()
#41 0xaaaaaaaa in ?? ()
#42 0x3fffaaaa in ?? ()
#43 0x912c4690 in ?? ()
#44 0x967b7dac in ?? ()
#45 0x800f169c in ?? ()
#46 0x91206700 in ?? ()
#47 0x00000001 in ?? ()
---Type <return> to continue, or q <return> to quit---
#48 0x967b7d9c in ?? ()
#49 0x800a9fc8 in ?? ()
#50 0x80105648 in ?? ()
#51 0x00000246 in ?? ()
#52 0x967b7dac in ?? ()
#53 0x80037213 in ?? ()
#54 0x967b7f14 in ?? ()
#55 0x912c4690 in ?? ()
#56 0x00000000 in ?? ()
#57 0x80043964 in ?? ()
#58 0x912c4600 in ?? ()
#59 0x002c46d8 in ves_icall_System_Runtime_InteropServices_Marshal_GetIUnknownForObjectInternal (object=0x1804db38)
    at /ToBe/Mono/mono/mono/metadata/marshal.c:10361
#60 0x180647fb in ?? ()
#61 0x1804db38 in ?? ()
#62 0x00000000 in ?? ()
#63 0x3f800000 in ?? ()
#64 0x00000000 in ?? ()
#65 0x00000000 in ?? ()
#66 0x7ffebf00 in ?? ()
#67 0x18064585 in ?? ()
#68 0x1804db38 in ?? ()
#69 0x00000000 in ?? ()
---Type <return> to continue, or q <return> to quit---
#70 0x3f800000 in ?? ()
#71 0x7ffebf10 in ?? ()
#72 0x185dcd96 in ?? ()
#73 0x1804db38 in ?? ()
#74 0x184f8194 in ?? ()
#75 0x7ffebf30 in ?? ()
#76 0x185dcc29 in ?? ()
#77 0x1804db38 in ?? ()
#78 0x1854e9b0 in ?? ()
#79 0x1854c6e0 in ?? ()
#80 0x1804db38 in ?? ()
#81 0x1801a230 in ?? ()
#82 0x7ffebf5c in ?? ()
#83 0x7ffebf5c in ?? ()
#84 0x1806416f in ?? ()
#85 0x00000000 in ?? ()
#86 0x00000000 in ?? ()
#87 0x00398208 in mono_jit_compile_method (method=0xffffffff)
    at /ToBe/Mono/mono/mono/mini/mini.c:14126
Previous frame inner to this frame (corrupt stack?)

Not using the *BSD stack size of 65536 but 4096 (suggested by Ingo) or 8192 (Darwin) leads to the system freezing: 

vm_page_fault: vm_soft_fault returned error 'Bad address' on fault at 0x70002007
create_thread: unable to create proper user stack!                              
CPU 0 halted!

With the EBX/EDI/ESI fixes in place, bootstrapping aborts without further information while executing mcs: 

Abort
Stacktrace:

Abort

However running a Hello World assembly using monolite works: 

> MONO_PATH=/path/to/mcs/class/lib/monolite \
 MONO_CFG_DIR=path/to/mono/runtime/etc \
 MONO_SHARED_DIR=path/to/mono/runtime \
 path/to/mono/mono/mini/mono --config path/to/mono/runtime/etc/mono/config hello.exe
Hello World.
* Assertion at /path/to/mono/mono/io-layer/handles-private.h:149, condition `thr_ret == 0' not met
Abort
Stacktrace:

Abort

So JIT'ing (incl. trampolines) already works! (Same assertion failure when running mcs without arguments.) (The assertion failure was fixed in Haiku r27253, so that a Hello World runs fine now.)

Test status

After copying over *.dll and *.exe after make rcheck in mini on another machine, running ./mono --regression basic.exe (set up to use monolite, cf. above) succeeds all tests, but once again shows the assertion failure. Same for basic-long.exe, basic-float.exe, basic-calls.exe, objects.exe and arrays.exe. exceptions.exe terminates with a DivideByZeroException. (iltests.exe and generics.exe cannot be run with monolite since they depend on the 2.0 profile.)

Notes on shared handles

At Haiku r26820 with SMP disabled in the bootmenu I get the following output from make: 

make[4]: Entering directory `/ToBe/Mono/mcs'
make PROFILE=basic all
make[5]: Entering directory `/ToBe/Mono/mcs'
Stacktrace:

  at (wrapper managed-to-native) System.IO.MonoIO.Open (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare,System.IO.FileOptions,System.IO.MonoIOError&) <0x00004>
  at (wrapper managed-to-native) System.IO.MonoIO.Open (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare,System.IO.FileOptions,System.IO.MonoIOError&) <0xffffffff>
  at System.IO.FileStream..ctor (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare,int,bool,System.IO.FileOptions) <0x00230>
  at System.IO.FileStream..ctor (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare) <0x0001f>
  at (wrapper remoting-invoke-with-check) System.IO.FileStream..ctor (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare) <0xffffffff>
  at System.IO.File.OpenRead (string) <0x00024>
  at Mono.CSharp.Driver.Parse (Mono.CSharp.CompilationUnit) <0x0001f>
  at Mono.CSharp.Driver.Parse () <0x00062>
  at Mono.CSharp.Driver.Compile () <0x00021>
  at Mono.CSharp.Driver.Main (string[]) <0x0005a>
  at (wrapper runtime-invoke) Mono.CSharp.Driver.runtime_invoke_int_string[] (object,intptr,intptr,intptr) <0xffffffff>
Abort
make[6]: *** [build/deps/basic-profile-check.exe] Abort
make[6]: Entering directory `/ToBe/Mono/mcs'
*** The contents of your 'monolite' directory may be out-of-date
*** You may want to try 'make get-monolite-latest'
make[6]: *** [do-profile-check-monolite] Error 1
make[6]: Leaving directory `/ToBe/Mono/mcs'
make[5]: *** [do-profile-check] Error 2
make[5]: Leaving directory `/ToBe/Mono/mcs'
make[4]: *** [profile-do--basic--all] Error 2

The corresponding serial output is in the  Ticket. At least it does not hang Haiku this way.

Executing my Hello World KDLs though ( Ticket): 

runtime_loader: cannot open file /ToBe/Mono/mcs/class/lib/monolite/mscorlib.dll.so
xsi_semget: key = 1292045451, numberOfSemaphores = 8, flags = 384
xsi_semop: semaphoreID = 1, ops = 0x7ffeebd4, numOps = 1
xsi_semop: semaphoreNumber = 6, value = 1
xsi_semop: semaphore acquired succesfully
XsiSemaphore::RecordUndo: new record added. Team = 49333, semaphoreSetID = 1, semaphoreNumber = 6, value = -1
xsi_semop: semaphoreID = 1, ops = 0x7ffeebd4, numOps = 1
xsi_semop: semaphoreNumber = 7, value = 0
xsi_semop: semaphore acquired succesfully
XsiSemaphore::RecordUndo: new record added. Team = 49333, semaphoreSetID = 1, semaphoreNumber = 7, value = 1
xsi_semop: semaphoreID = 1, ops = 0x7ffeebc4, numOps = 1
xsi_semop: semaphoreNumber = 6, value = 0
xsi_semop: semaphore acquired succesfully
XsiSemaphore::RecordUndo: found record. Team = 49333, semaphoreSetID = 1, semaphoreNumber = 6, value = -1
xsi_semop: semaphoreID = 1, ops = 0x7ffee844, numOps = 1
xsi_semop: semaphoreNumber = 3, value = 1
xsi_semop: semaphore acquired succesfully
XsiSemaphore::RecordUndo: new record added. Team = 49333, semaphoreSetID = 1, semaphoreNumber = 3, value = -1
xsi_semop: semaphoreID = 1, ops = 0x7ffee844, numOps = 1
xsi_semop: semaphoreNumber = 3, value = 0
xsi_semop: semaphore acquired succesfully
XsiSemaphore::RecordUndo: found record. Team = 49333, semaphoreSetID = 1, semaphoreNumber = 3, value = -1
runtime_loader: cannot open file /ToBe/Mono/hello.exe.so
runtime_loader: cannot open file /ToBe/Mono/hello.exe.so
runtime_loader: cannot open file /ToBe/Mono/mcs/class/lib/monolite/mscorlib.dll.so
xsi_semop: semaphoreID = 1, ops = 0x7ffee800, numOps = 1
xsi_semop: semaphoreNumber = 2, value = 1
xsi_semop: semaphore acquired succesfully
XsiSemaphore::RecordUndo: new record added. Team = 49333, semaphoreSetID = 1, semaphoreNumber = 2, value = -1
xsi_semop: semaphoreID = 1, ops = 0x7ffee7f0, numOps = 1
xsi_semop: semaphoreNumber = 2, value = 0
xsi_semop: semaphore acquired succesfully
XsiSemaphore::RecordUndo: found record. Team = 49333, semaphoreSetID = 1, semaphoreNumber = 2, value = -1
xsi_semop: semaphoreID = 1, ops = 0x7ffee800, numOps = 1
xsi_semop: semaphoreNumber = 2, value = 1
xsi_semop: semaphore acquired succesfully
XsiSemaphore::RecordUndo: found record. Team = 49333, semaphoreSetID = 1, semaphoreNumber = 2, value = 0
xsi_semop: semaphoreID = 1, ops = 0x7ffee7f0, numOps = 1
xsi_semop: semaphoreNumber = 2, value = 0
xsi_semop: semaphore acquired succesfully
XsiSemaphore::RecordUndo: found record. Team = 49333, semaphoreSetID = 1, semaphoreNumber = 2, value = -1
xsi_semop: semaphoreID = 1, ops = 0x7ffee800, numOps = 1
xsi_semop: semaphoreNumber = 2, value = 1
xsi_semop: semaphore acquired succesfully
XsiSemaphore::RecordUndo: found record. Team = 49333, semaphoreSetID = 1, semaphoreNumber = 2, value = 0
xsi_semop: semaphoreID = 1, ops = 0x7ffee7f0, numOps = 1
xsi_semop: semaphoreNumber = 2, value = 0
xsi_semop: semaphore acquired succesfully
XsiSemaphore::RecordUndo: found record. Team = 49333, semaphoreSetID = 1, semaphoreNumber = 2, value = -1
xsi_semop: semaphoreID = 1, ops = 0x7ffee85c, numOps = 1
xsi_semop: semaphoreNumber = 3, value = 1
xsi_semop: semaphore acquired succesfully
XsiSemaphore::RecordUndo: found record. Team = 49333, semaphoreSetID = 1, semaphoreNumber = 3, value = 0
xsi_semop: semaphoreID = 1, ops = 0x7ffee85c, numOps = 1
xsi_semop: semaphoreNumber = 3, value = 0
xsi_semop: semaphore acquired succesfully
XsiSemaphore::RecordUndo: found record. Team = 49333, semaphoreSetID = 1, semaphoreNumber = 3, value = -1
xsi_semop: semaphoreID = 1, ops = 0x7ffee35c, numOps = 1
xsi_semop: semaphoreNumber = 3, value = 1
xsi_semop: semaphore acquired succesfully
XsiSemaphore::RecordUndo: found record. Team = 49333, semaphoreSetID = 1, semaphoreNumber = 3, value = 0
xsi_semop: semaphoreID = 1, ops = 0x7ffee35c, numOps = 1
xsi_semop: semaphoreNumber = 3, value = 0
xsi_semop: semaphore acquired succesfully
XsiSemaphore::RecordUndo: found record. Team = 49333, semaphoreSetID = 1, semaphoreNumber = 3, value = -1
xsi_semop: semaphoreID = 1, ops = 0x7ffee87c, numOps = 1
xsi_semop: semaphoreNumber = 6, value = 1
xsi_semop: semaphore acquired succesfully
XsiSemaphore::RecordUndo: found record. Team = 49333, semaphoreSetID = 1, semaphoreNumber = 6, value = 0
xsi_semctl: semaphoreID = 1, semaphoreNumber = 7, command = 4
xsi_semctl: semaphoreID = 1, semaphoreNumber = 0, command = 0
XsiSemaphoreSet::~XsiSemaphoreSet(): removing semaphore set
XsiSemaphore::ClearUndos: semaphoreSetID = 1, semaphoreNumber = 0
XsiSemaphore::ClearUndos: semaphoreSetID = 1, semaphoreNumber = 1
XsiSemaphore::ClearUndos: semaphoreSetID = 1, semaphoreNumber = 2
XsiSemaphore::ClearUndos: semaphoreSetID = 1, semaphoreNumber = 3
XsiSemaphore::ClearUndos: semaphoreSetID = 1, semaphoreNumber = 4
XsiSemaphore::ClearUndos: semaphoreSetID = 1, semaphoreNumber = 5
XsiSemaphore::ClearUndos: semaphoreSetID = 1, semaphoreNumber = 6
XsiSemaphore::ClearUndos: semaphoreSetID = 1, semaphoreNumber = 7
PANIC: _mutex_lock(): double lock of 0x90eb7318 by thread 49333
Welcome to Kernel Debugging Land...
Thread 49333 "mono" running on CPU 0
kdebug> bt
stack trace for thread 49333 "mono"
    kernel stack: 0x93f30000 to 0x93f34000
      user stack: 0x7efef000 to 0x7ffef000
frame            caller     <image>:function + offset
 0 93f336f4 (+  48) 80054379   <kernel>:invoke_debugger_command + 0x00ed
 1 93f33724 (+  64) 80054171   <kernel>:invoke_pipe_segment__FP21debugger_command_pipelPc + 0x0079
 2 93f33764 (+  64) 800544b9   <kernel>:invoke_debugger_command_pipe + 0x009d
 3 93f337a4 (+  48) 80055394   <kernel>:_ParseCommandPipe__16ExpressionParserRi + 0x0234
 4 93f337d4 (+  48) 80054d4a   <kernel>:EvaluateCommand__16ExpressionParserPCcRi + 0x01de
 5 93f33804 (+ 224) 80056760   <kernel>:evaluate_debug_command + 0x0088
 6 93f338e4 (+  64) 800527ee   <kernel>:kernel_debugger_loop__Fv + 0x01ae
 7 93f33924 (+  48) 80053387   <kernel>:kernel_debugger + 0x0117
 8 93f33954 (+ 192) 80053265   <kernel>:panic + 0x0029
 9 93f33a14 (+  64) 8003765c   <kernel>:_mutex_lock + 0x00e0
10 93f33a54 (+  64) 8002e58f   <kernel>:file_cache_set_size + 0x003b
11 93f33a94 (+  48) 80593878   <bfs>:SetFileSize__5InodeR11Transactionx + 0x00bc
12 93f33ac4 (+ 352) 80593a5d   <bfs>:Free__5InodeR11Transaction + 0x0029
13 93f33c24 (+  80) 8059c343   <bfs>:bfs_remove_vnode__FP9fs_volumeP8fs_vnodeb + 0x00b3
14 93f33c74 (+  48) 80083b5f   <kernel>:free_vnode__FP5vnodeb + 0x00af
15 93f33ca4 (+  48) 80083cf5   <kernel>:dec_vnode_ref_count__FP5vnodebT1 + 0x0119
16 93f33cd4 (+  32) 800883ea   <kernel>:vfs_put_vnode + 0x001e
17 93f33cf4 (+  32) 8002f899   <kernel>:ReleaseStoreRef__12VMVnodeCache + 0x0015
18 93f33d14 (+  48) 800abaf7   <kernel>:RemoveArea__7VMCacheP7vm_area + 0x006f
19 93f33d44 (+  64) 800a4cbb   <kernel>:delete_area__FP16vm_address_spaceP7vm_area + 0x009b
20 93f33d84 (+  48) 800a6ba9   <kernel>:vm_delete_areas + 0x0079
21 93f33db4 (+  48) 800aa6bb   <kernel>:vm_delete_address_space + 0x0033
22 93f33de4 (+  96) 80049531   <kernel>:team_delete_team + 0x0245
23 93f33e44 (+ 128) 8004cb4c   <kernel>:thread_exit + 0x0364
24 93f33ec4 (+  64) 80042d00   <kernel>:handle_signals + 0x0384
25 93f33f04 (+  64) 8004cf4e   <kernel>:thread_at_kernel_exit + 0x0076
26 93f33f44 (+ 100) 800b69cb   <kernel>:kernel_exit_handle_signals + 0x0006 (nearest)
user iframe at 0x93f33fa8 (end = 0x93f34000)
 eax 0x0            ebx 0x6beb38        ecx 0x7ffee928   edx 0x200246
 esi 0x6c2760       edi 0x1             ebp 0x7ffee954   esp 0x93f33fdc
 eip 0xffff0104  eflags 0x200217   user esp 0x7ffee928
 vector: 0x63, error code: 0x0
27 93f33fa8 (+   0) ffff0104
7ffee954 -- read fault
kdebug>