Bug 3272 - SIGSEGV during debugging
Summary: SIGSEGV during debugging
Status: RESOLVED FIXED
Alias: None
Product: Runtime
Classification: Mono
Component: Debugger ()
Version: unspecified
Hardware: PC Linux
: --- normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2012-02-08 11:26 UTC by Marek Safar
Modified: 2012-02-19 10:14 UTC (History)
6 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 Marek Safar 2012-02-08 11:26:11 UTC
using System;

class C
{
    public static void Main ()
    {
	var a = new [] { 1, 3, 4, 4 }; // Set a breakpoint here and F11
    }
}

This is not 100% reliably reproducible.

After F11 on double click on any row in StackFrame window (there should be 2 it does not matter which one) and continue debugging. After step out debugger crashes with

Stacktrace:


Native stacktrace:

	/home/marek/mono/bin/mono() [0x4973c7]
	/home/marek/mono/bin/mono() [0x4eb41f]
	/home/marek/mono/bin/mono() [0x4197d9]
	/lib/x86_64-linux-gnu/libpthread.so.0(+0xfc60) [0x2ad695809c60]
	/home/marek/mono/bin/mono() [0x4eb10f]
	/home/marek/mono/bin/mono() [0x4953e6]
	/home/marek/mono/bin/mono() [0x496113]
	/home/marek/mono/bin/mono() [0x4962e1]
	/home/marek/mono/bin/mono() [0x4b4a09]
	/home/marek/mono/bin/mono() [0x4b5c31]
	/home/marek/mono/bin/mono() [0x4bd7b1]
	/home/marek/mono/bin/mono() [0x4b4d33]
	[0x40bbef00]

Debug info from gdb:

Could not attach to process.  If your uid matches the uid of the target
process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
again as the root user.  For more details, see /etc/sysctl.d/10-ptrace.conf
ptrace: Operation not permitted.

=================================================================
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.
=================================================================
Comment 1 Marek Safar 2012-02-08 11:38:49 UTC
It'd be also good to fix the stack trace in this case. It's quite confusing
Comment 2 Zoltan Varga 2012-02-08 19:00:01 UTC
What does 'continue debugging' means ? What exact steps cause the crash ?
Comment 3 Zoltan Varga 2012-02-08 19:00:56 UTC
I can repro it.
Comment 4 Zoltan Varga 2012-02-08 19:47:32 UTC
The crash is fixed in master. Whats the problem with the stack trace ?
Comment 5 Marek Safar 2012-02-09 04:15:09 UTC
The stack trace is wrong from user perspective. It indicates there is a direct link between Main and string static ctor which is wrong.
Comment 6 Miguel de Icaza [MSFT] 2012-02-14 12:07:37 UTC
Is this something that we need in mobile-master?
Comment 7 Zoltan Varga 2012-02-14 12:17:57 UTC
No.
Comment 8 Jeffrey Stedfast 2012-02-16 17:26:16 UTC
what is F11? is that step in? out? or over?
Comment 9 Marek Safar 2012-02-17 12:18:51 UTC
F11: Step into
Comment 10 Jeffrey Stedfast 2012-02-17 13:51:53 UTC
I'm only getting one frame (I missed this part before):

C.Main ()
Comment 11 Marek Safar 2012-02-17 15:06:37 UTC
I have enabled framework debugging.
Comment 12 Jeffrey Stedfast 2012-02-17 15:37:50 UTC
okay, got it now.

Seems to either be a runtime issue (why is the string ctor being called?) or a compiler issue for generating debugging symbols for static ctors (seems that VS does not generate symbols for static ctors)
Comment 13 Marek Safar 2012-02-18 07:17:43 UTC
compiler is correct here, it's generating symbols for static initializers (same as VS does)
Comment 14 Mikayla Hutchinson [MSFT] 2012-02-18 14:46:35 UTC
In VS, when stepping into code that causes a user-code cctor to run, the VS debugger logs a message that says it stepped through the cctor method because it has no symbols. Is this message incorrect?
Comment 15 Marek Safar 2012-02-19 05:41:54 UTC
Michael, I am not sure that's the best approach here.

At the moment the stack trace looks like this

string..cctor () in /home/marek/git/mono/mcs/class/corlib/System/String.cs:64
C.Main () in /home/marek/Projects/g2/g2/Main.cs:7

Which is not correct. I think JIT makes string static cctor call whenever is JIT-ing string (I can be wrong as I am no mono JIT expert). In that case the stack should probably look like

string..cctor ()
RuntimeHelpers.InitializeArray
C.Main ()
Comment 16 Zoltan Varga 2012-02-19 06:15:01 UTC
The runtime runs type initializers on demand, so this is perfectly normal. Perhaps we need to add an option to sdb to avoid stopping during single stepping in class initializers unless requested, i.e.:
http://msdn.microsoft.com/en-us/library/ms231219.aspx
Comment 17 Zoltan Varga 2012-02-19 10:14:18 UTC
This has been fixed in sdb/md master.