Bug 314050 (MONO55253) - SIGSEGV handling broken on some linux distros
Summary: SIGSEGV handling broken on some linux distros
Status: RESOLVED FIXED
Alias: MONO55253
Product: Mono: Runtime
Classification: Mono
Component: misc (show other bugs)
Version: unspecified
Hardware: Other Other
: P3 - Medium : Major
Target Milestone: ---
Assignee: Mono Bugs
QA Contact: Mono Bugs
URL:
Whiteboard:
Keywords: Built
Depends on:
Blocks:
 
Reported: 2004-03-06 16:19 UTC by David Sheldon
Modified: 2010-03-14 11:35 UTC (History)
1 user (show)

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


Attachments
gzipped trace output of mono --trace -v -v -v -v (10.01 KB, application/gzip)
2004-03-08 19:29 UTC, Thomas Wiest
Details
C testcase (1.71 KB, text/plain)
2004-03-10 18:49 UTC, Thomas Wiest
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Wiest 2007-09-15 18:29:26 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".