[Mono-bugs] [Bug 346160] FieldInfo.GetValue does not check type of object

bugzilla_noreply at novell.com bugzilla_noreply at novell.com
Wed Dec 5 08:19:44 EST 2007


https://bugzilla.novell.com/show_bug.cgi?id=346160

User gert.driesen at pandora.be added comment
https://bugzilla.novell.com/show_bug.cgi?id=346160#c1


Gert Driesen <gert.driesen at pandora.be> changed:

           What    |Removed                                         |Added
----------------------------------------------------------------------------
                 CC|                                                |gert.driesen at pandora.be
            Summary|Mono core dumps when reaching uninitialized     |FieldInfo.GetValue does not check type of object
                   |object through reflection                       |




--- Comment #1 from Gert Driesen <gert.driesen at pandora.be>  2007-12-05 06:19:43 MST ---
The problem is not the fact that the field is not initialized. The SIGSEGV is
triggered by passing a Type to FieldInfo.GetValue.

Currently, we do not check whether the type of the FieldInfo can be assigned
from the type of the value passed.

I've attached a more complete repro.

Expected result:

=== A ===
SUCCESS
=== B ===
SUCCESS
=== C ===
SUCCESS
=== D ===
SUCCESS

Actual result:

=== A === 
SUCCESS
=== B === 
SUCCESS
=== C === 
FAILURE:NULL
=== D === 
Stacktrace:


Native stacktrace:

        mono [0x817032e]
        mono [0x807ee21]
        [0xffffe440]

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 -1211459888 (LWP 27698)]
[New Thread -1220719728 (LWP 27700)]
[New Thread -1220572272 (LWP 27699)]
0xffffe410 in __kernel_vsyscall ()
  3 Thread -1220572272 (LWP 27699)  0xffffe410 in __kernel_vsyscall ()
  2 Thread -1220719728 (LWP 27700)  0xffffe410 in __kernel_vsyscall ()
  1 Thread -1211459888 (LWP 27698)  0xffffe410 in __kernel_vsyscall ()

Thread 3 (Thread -1220572272 (LWP 27699)):
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7e269f6 in ?? () from /lib/tls/i686/cmov/libpthread.so.0
#2  0x08116751 in collection_thread (unused=0x0) at collection.c:34
#3  0xb7e1f46b in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#4  0xb7d7e6de in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 2 (Thread -1220719728 (LWP 27700)):
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7e23676 in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/tls/i686/cmov/libpthread.so.0
#2  0x08108abf in timedwait_signal_poll_cond (cond=0xb78d21dc, 
    mutex=0xb78d21c4, timeout=0x0, alertable=0) at handles.c:1443
#3  0x0810b55f in _wapi_handle_timedwait_signal_handle (handle=0x404, 
    timeout=0x0, alertable=0) at handles.c:1523
#4  0x0810b5dc in _wapi_handle_wait_signal_handle (handle=0x404, alertable=0)
    at handles.c:1483
#5  0x08107cff in WaitForSingleObjectEx (handle=0x404, timeout=4294967295, 
    alertable=0) at wait.c:200
#6  0x080d155a in finalizer_thread (unused=0x0) at gc.c:888
#7  0x080f1964 in start_wrapper (data=0x82516b8) at threads.c:569
#8  0x08117cf2 in thread_start_routine (args=0xb777e768) at threads.c:264
#9  0x0812bed5 in GC_start_routine (arg=0x22f40) at pthread_support.c:1369
#10 0xb7e1f46b in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#11 0xb7d7e6de in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 1 (Thread -1211459888 (LWP 27698)):
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7d3df69 in fork () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7e28874 in fork () from /lib/tls/i686/cmov/libpthread.so.0
#3  0xb7e95ab9 in ?? () from /usr/lib/libglib-2.0.so.0
#4  0x00000010 in ?? ()
#5  0x00000010 in ?? ()
#6  0x08256860 in ?? ()
#7  0xb7df2170 in ?? () from /lib/tls/i686/cmov/libc.so.6
#8  0x08256860 in ?? ()
#9  0xe96258b8 in ?? ()
#10 0xb7d15071 in ?? () from /lib/tls/i686/cmov/libc.so.6
#11 0x00000010 in ?? ()
#12 0x00000010 in ?? ()
#13 0x00000010 in ?? ()
#14 0xb7b751a4 in ?? ()
#15 0xb7d16fc0 in malloc () from /lib/tls/i686/cmov/libc.so.6
#16 0xb7e966ab in g_spawn_sync () from /usr/lib/libglib-2.0.so.0
#17 0xb7e96b4c in g_spawn_command_line_sync () from /usr/lib/libglib-2.0.so.0
#18 0x081703c9 in mono_handle_native_sigsegv (signal=11, ctx=0xb7b75d0c)
    at mini-exceptions.c:1061
#19 0x0807ee21 in mono_arch_handle_altstack_exception (sigctx=0xb7b75d0c, 
    fault_addr=0x0, stack_ovf=0) at exceptions-x86.c:854
#20 <signal handler called>
#21 0xb7b0ce4f 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.
=================================================================


-- 
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.


More information about the mono-bugs mailing list