Bug 5913 - csharp repl segfaulting with structs
Summary: csharp repl segfaulting with structs
Status: RESOLVED FIXED
Alias: None
Product: Compilers
Classification: Mono
Component: C# ()
Version: unspecified
Hardware: PC Linux
: --- normal
Target Milestone: ---
Assignee: Marek Safar
URL:
Depends on:
Blocks:
 
Reported: 2012-06-28 19:13 UTC by Jérémie Laval
Modified: 2012-09-06 15:08 UTC (History)
3 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED FIXED

Description Jérémie Laval 2012-06-28 19:13:10 UTC
Mono JIT compiler version 2.11.2 (master/72c8960 dim. juin 24 23:02:07 IST 2012)

Input:

csharp> struct A { public string foo; public int bar; }
csharp> A aStruct = new A { foo = "foo", bar = 1 };

Result:

segfault with no stacktrace. Seems to be a stack smash.

(gdb) t apply all bt

Thread 3 (Thread 0x7ffff5c64700 (LWP 12358)):
#0  0x00007ffff74cb860 in sem_wait () from /lib/libpthread.so.0
#1  0x00000000005d3608 in mono_sem_wait (sem=sem@entry=0x92f360, alertable=alertable@entry=1) at mono-semaphore.c:113
#2  0x000000000052079b in finalizer_thread (unused=unused@entry=0x0) at gc.c:1084
#3  0x00000000005a3705 in start_wrapper_internal (data=0xa4b750) at threads.c:576
#4  start_wrapper (data=0xa4b750) at threads.c:622
#5  0x00000000005cd0d9 in thread_start_routine (args=args@entry=0x9c2160) at wthreads.c:286
#6  0x00000000005d4ee9 in inner_start_thread (arg=0xa39770) at mono-threads-posix.c:49
#7  0x00000000005f34da in GC_start_routine (arg=0x7ffff5c65fc0) at pthread_support.c:1508
#8  0x00007ffff74c5e0e in start_thread () from /lib/libpthread.so.0
#9  0x00007ffff72011ed in clone () from /lib/libc.so.6

Thread 2 (Thread 0x7ffff6f19700 (LWP 12357)):
#0  0x00007ffff74c98f4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#1  0x00000000005f385c in GC_wait_marker () at pthread_support.c:1903
#2  0x00000000005ecffa in GC_help_marker (my_mark_no=10) at mark.c:1116
#3  0x00000000005f2521 in GC_mark_thread (id=0x0) at pthread_support.c:557
#4  0x00007ffff74c5e0e in start_thread () from /lib/libpthread.so.0
#5  0x00007ffff72011ed in clone () from /lib/libc.so.6

Thread 1 (Thread 0x7ffff7fbe740 (LWP 12354)):
#0  0x0000000000000001 in ?? ()
#1  0x00007ffff5081e60 in ?? ()
#2  0x00007ffff4e87f08 in ?? ()
#3  0x00007fffffffdd9f in ?? ()
#4  0x00007fffffffdd90 in ?? ()
#5  0x00007ffff7e50d70 in ?? ()
#6  0x00000000009e3788 in ?? ()
#7  0x00007ffff5302020 in ?? ()
#8  0x0000000000000000 in ?? ()
Comment 1 Marek Safar 2012-06-29 06:29:15 UTC
SRE should not crash and it does not .NET
Comment 2 Zoltan Varga 2012-06-30 20:16:46 UTC
I'm not sure why running with --security=validil doesn't catch this, but 'A' doesn't seem to be declared as a valuetype by 'csharp', i.e. its parent is 'Object'.
Comment 3 Zoltan Varga 2012-08-07 17:03:39 UTC
mareks: this seems to be an mcs problem.
Comment 4 Zoltan Varga 2012-08-15 00:09:21 UTC
-> mcs.
Comment 5 Marek Safar 2012-09-06 15:08:43 UTC
Fixed in master