Bug 324696 (MONO82022) - SIGSEGV loading enum with no value__ field
Summary: SIGSEGV loading enum with no value__ field
Status: RESOLVED FIXED
Alias: MONO82022
Product: Mono: Runtime
Classification: Mono
Component: misc (show other bugs)
Version: 1.2
Hardware: Other All
: P3 - Medium : Normal
Target Milestone: ---
Assignee: Rodrigo Kumpera
QA Contact: Mono Bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-07-06 12:58 UTC by Gert Driesen
Modified: 2007-11-08 16:24 UTC (History)
0 users

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
IL source (1.34 KB, text/plain)
2007-07-06 13:00 UTC, Thomas Wiest
Details
First take on fixing it (437 bytes, patch)
2007-07-06 19:06 UTC, Thomas Wiest
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Wiest 2007-09-15 20:43:15 UTC


---- Reported by gert.driesen@pandora.be 2007-07-06 05:58:33 MST ----

When an enum containing no value__ field is loaded, a TypeLoadException 
should be thrown. However, on Mono this results in a SIGSEGV.

To reproduce:
1. compile the attached IL (using ilasm /exe test.il)
2. run the assembly.

Expected result:

Unhandled Exception: System.TypeLoadException: No Instance Field in an 
Enum. (MS .NET 2.0)
-or-
Unhandled Exception: System.TypeLoadException: Could not load type 
FieldAttributes from assembly test, Version=0.0.0.0, Culture=neutral, 
PublicKeyToken=null. (MS.NET 1.1)

Actual result:

Stacktrace:


Native stacktrace:

	mono [0x815c33e]
	mono [0x8127208]
	[0xffffe440]
	mono [0x80a76da]
	mono(mono_class_get_full+0xaf) [0x80a7caf]
	mono(mono_ldtoken+0x66) [0x80ae956]
	mono [0x813706a]
	mono [0x8147f0d]
	mono [0x81498ae]
	mono [0x8149edb]
	mono(mono_runtime_exec_main+0xbb) [0x80efb1b]
	mono(mono_runtime_run_main+0x1b9) [0x80efe59]
	mono(mono_main+0xecb) [0x805ac5b]
	mono [0x8059882]
	/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xdc) [0xb7cd2ebc]
	mono [0x80597d1]

Debug info from gdb:

Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -1211386144 (LWP 5698)]
[New Thread -1220482160 (LWP 5700)]
[New Thread -1214735472 (LWP 5699)]
0xffffe410 in __kernel_vsyscall ()
  3 Thread -1214735472 (LWP 5699)  0xffffe410 in __kernel_vsyscall ()
  2 Thread -1220482160 (LWP 5700)  0xffffe410 in __kernel_vsyscall ()
  1 Thread -1211386144 (LWP 5698)  0xffffe410 in __kernel_vsyscall ()

Thread 3 (Thread -1214735472 (LWP 5699)):
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7e31986 in ?? () from /lib/tls/i686/cmov/libpthread.so.0
#2  0x0810bda4 in collection_thread (unused=0x0) at collection.c:34
#3  0xb7e2a31b in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#4  0xb7d8c57e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 2 (Thread -1220482160 (LWP 5700)):
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7e2e5c6 in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/tls/i686/cmov/libpthread.so.0
#2  0x080ffd5f in timedwait_signal_wait_cond (cond=0xb78f81dc, 
    mutex=0xb78f81c4, timeout=0x0, alertable=0, waiting_on=0x404)
    at handles.c:1424
#3  0x08101aec in _wapi_handle_wait_signal_handle (handle=0x404, 
alertable=0)
    at handles.c:1486
#4  0x080fe26f in WaitForSingleObjectEx (handle=0x404, timeout=4294967295, 
    alertable=0) at wait.c:200
#5  0x080caeda in finalizer_thread (unused=0x0) at gc.c:835
#6  0x080e96e4 in start_wrapper (data=0x8236ba0) at threads.c:319
#7  0x0810d672 in thread_start_routine (args=0xb77a4768) at threads.c:253
#8  0x0811f5e5 in GC_start_routine (arg=0x22f40) at pthread_support.c:1362
#9  0xb7e2a31b in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#10 0xb7d8c57e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 1 (Thread -1211386144 (LWP 5698)):
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7d4cf59 in fork () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7e337e4 in fork () from /lib/tls/i686/cmov/libpthread.so.0
#3  0xb7e987d9 in ?? () from /usr/lib/libglib-2.0.so.0
#4  0x00000010 in ?? ()
#5  0xb7dfb128 in ?? () from /lib/tls/i686/cmov/libc.so.6
#6  0xb7dfb150 in ?? () from /lib/tls/i686/cmov/libc.so.6
#7  0x00000018 in ?? ()
#8  0x00000000 in ?? ()
#0  0xffffe410 in __kernel_vsyscall ()


=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=================================================================



---- Additional Comments From gert.driesen@pandora.be 2007-07-06 06:00:35 MST ----

Created an attachment (id=172247)
IL source




---- Additional Comments From kumpera@gmail.com 2007-07-06 12:05:46 MST ----

The function mono_class_create_from_typedef in metadata/class.c
doesn't check if the enum field is missing. Attached is a patch that
fixes it.




---- Additional Comments From kumpera@gmail.com 2007-07-06 12:06:39 MST ----

Created an attachment (id=172248)
First take on fixing it




---- Additional Comments From kumpera@gmail.com 2007-07-10 10:54:14 MST ----

Fix required calling mono_class_set_failure, thanks Paolo for pointing
it. Commited in r81709.



---- Additional Comments From gert.driesen@pandora.be 2007-07-11 02:02:56 MST ----

Thanks for the fix!

Just a small detail, but is it still necessary to write a warning in 
mono_loader_set_error_type_load ?



---- Additional Comments From kumpera@gmail.com 2007-07-11 15:29:19 MST ----

The comment in mono_loader_set_error_type_load suggests that it still
makes sense.

But I think mono show throw a TypeLoadException with a more
informative message than it currently does.

Imported an attachment (id=172247)
Imported an attachment (id=172248)
Comment 1 Rodrigo Kumpera 2007-11-08 16:24:20 UTC
This bug has been fixed for quite a while. The issue of improved error reporting on TypeLoadException should be tracked on another issue.

I created #340261 to track this enhancement.