Bugzilla – Bug 314050
SIGSEGV handling broken on some linux distros
Last modified: 2010-03-14 11:35:36 UTC
---- Reported by dave-mono@earth.li 2004-03-06 09:19:22 MST ---- Please fill in this template when reporting a bug, unless you know what you are doing. Description of Problem: If you do ((string)null).IndexOf('a'); it will never return. Steps to reproduce the problem: 1. using System; class t1 { static void Main(string [] args ) { Console.WriteLine(((string)null).IndexOf('a')); } } 2. compile, run Actual Results: - Busy hang Expected Results: - Unhandled Exception: System.NullReferenceException: Object reference no an instance of an object. at t1.Main(String[] args) How often does this happen? All the time. ---- Additional Comments From dave-mono@earth.li 2004-03-06 11:01:04 MST ---- Thinking about it some more, I think that this might be a runtime bug. I think all callvirts on null objects are causing this problem. using System; public class Test { void foo () { } public static void Main() { Test bar = null; bar.foo(); } } ---- Additional Comments From bmaurer@users.sf.net 2004-03-07 00:35:38 MST ---- This is weird. Miguel, does this have to do with the callvirt changes we made? I thought we had fixed all the regressions. ---- Additional Comments From vargaz@freemail.hu 2004-03-08 11:59:18 MST ---- I'm unable to reproduce this. Please check that you are compiling the testcase with the latest version of mcs, since some versions mistakenly emitted a call instead of a callvirt. ---- Additional Comments From dave-mono@earth.li 2004-03-08 12:09:15 MST ---- Monodis is definately giving me: // method line 3 .method public static default void 'Main' () cil managed { // Method begins at RVA 0x20f6 .entrypoint // Code size 9 (0x9) .maxstack 2 .locals init ( class 'Test' V_0) IL_0000: ldnull IL_0001: stloc.0 IL_0002: ldloc.0 IL_0003: callvirt instance void class 'Test'::'foo'() IL_0008: ret } // end of method Test::default void 'Main' () I am using an mcs and mono made from CVS on Saturday. Is there anything else I can do to help? ---- Additional Comments From vargaz@freemail.hu 2004-03-08 12:22:49 MST ---- Could you run the test case with mono --trace -v -v -v -v and attach the output to this bug? Also, what OS/distribution are you using ? ---- Additional Comments From dave-mono@earth.li 2004-03-08 12:29:53 MST ---- Created an attachment (id=165700) gzipped trace output of mono --trace -v -v -v -v ---- Additional Comments From dave-mono@earth.li 2004-03-08 12:30:32 MST ---- I am using Linux, debian sid on Intel. ---- Additional Comments From vargaz@freemail.hu 2004-03-08 12:40:15 MST ---- This might be caused by my changes to NullReferenceException handling. Could you comment out the following line: #define MONO_ARCH_SIGSEGV_ON_ALTSTACK in mono/mono/mini/mini-x86.h, rebuild, and see if this makes a difference ? ---- Additional Comments From dave-mono@earth.li 2004-03-08 12:55:15 MST ---- Yes that appears to work. ---- Additional Comments From vargaz@freemail.hu 2004-03-10 11:49:52 MST ---- Created an attachment (id=165701) C testcase ---- Additional Comments From vargaz@freemail.hu 2004-03-10 11:50:23 MST ---- We need a new configure check for this. Could you run the attached test program and tell me the results ? It can be compiled with gcc altstacktest.c -lpthread. ---- Additional Comments From dave-mono@earth.li 2004-03-10 11:58:08 MST ---- I get: $ ./a.out THREAD: 0x4002 ALTSTACK: 0xbf7fdae4-0xbf7ffae4. THREAD: 0x8003 ALTSTACK: 0xbf5fdae4-0xbf5ffae4. THREAD: 0x4002 SP: 0xbf7ff770. Caught SIGSEGV. signal handler stack pointer = 0xbf7ff760 THREAD: 0x8003 SP: 0xbf5ff770. Caught SIGSEGV. signal handler stack pointer = 0xbf5ff760 ---- Additional Comments From vargaz@freemail.hu 2004-03-10 15:50:05 MST ---- It would be good if somebody could track down what is wrong with using sigaltstack in the runtime, and produce a test case which we could use at configure time. In the meantime, there is a new switch to configure: --with-sigaltstack=no can be used to turn off sigaltstack usage. ---- Additional Comments From gonzalo@ximian.com 2004-03-21 02:19:52 MST ---- The testing code is in configure.in now. Imported an attachment (id=165700) Imported an attachment (id=165701) Unknown operating system unknown. Setting to default OS "Other".