| Age | Commit message (Collapse) | Author |
|---|
|
-> throw in a async task with a try catch in the caller -> don't stop
-> throw in a new thread with a try catch in the caller -> stop
-> throw in the main thread without any try catch -> stop
Including a new test to test the fix of #17601.
Fixing #16588, create a while 1 to stops the program execution when an exception is thrown and no try catch is found and MONO_DEBUG=suspend-on-unhandled.
Fixes #17601
Fixes #16588
|
|
from alstack handling (#17922)
### Backstory
This test is failing in the interpreter (ONLY on Debian9/amd64. Not Ubuntu/amd64. Not macOS/amd64):
https://github.com/mono/mono/blob/0fed03ed63ed4ea742c4511d8edc3bc1c6f4044f/mcs/class/Mono.Debugger.Soft/Test/dtest.cs#L2484-L2499
Where the debuggee is just some unsafe code that tries to read from unmapped memory, thus causing a segfault.
So the test expects the runtime to send a CRASH event via the managed debugger interface. This happens very late in the crash handling machinery:
https://github.com/mono/mono/blob/0fed03ed63ed4ea742c4511d8edc3bc1c6f4044f/mono/mini/mini-posix.c#L1105
However, the runtime would never reach that, because it silently crashes when calling `backtrace`:
https://github.com/mono/mono/blob/0fed03ed63ed4ea742c4511d8edc3bc1c6f4044f/mono/mini/mini-posix.c#L939
At the point where the SIGSEGV happens, the native stack trace looks like this:
```
Thread 1 "mono-sgen" received signal SIGSEGV, Segmentation fault.
interp_exec_method_full (frame=0x555555c51f18, context=0x555555c38350, clause_args=clause_args@entry=0x0, error=0x555555c53f18, error@entry=0x7fffffffd8b0) at interp/interp.c:4463
4463 sp[-1].data.i = *(gint32*)sp[-1].data.p;
(gdb) bt
%0 interp_exec_method_full (frame=0x555555c51f18, context=0x555555c38350, clause_args=clause_args@entry=0x0, error=0x555555c53f18, error@entry=0x7fffffffd8b0) at interp/interp.c:4463
%1 0x000055555569237a in interp_runtime_invoke (method=<optimized out>, obj=<optimized out>, params=<optimized out>, exc=0x0, error=0x7fffffffd8b0) at interp/interp.c:1900
%2 0x0000555555590745 in mono_jit_runtime_invoke (method=0x555555bfdc38, obj=<optimized out>, params=0x7fffffffd858, exc=0x0, error=0x7fffffffd8b0) at mini-runtime.c:3001
%3 0x0000555555778c4c in do_runtime_invoke (method=0x555555bfdc38, obj=<optimized out>, params=<optimized out>, exc=<optimized out>, error=0x7fffffffd8b0) at object.c:3052
%4 0x000055555577b7d0 in do_exec_main_checked (method=0x555555bfdc38, args=<optimized out>, error=0x7fffffffd8b0) at object.c:5184
%5 0x000055555559a2aa in mono_jit_exec_internal (argv=0x7fffffffdcb8, argc=1, assembly=0x0, domain=0x555555bf9d40) at driver.c:1320
%6 mono_jit_exec (domain=domain@entry=0x555555bf9d40, assembly=assembly@entry=0x555555c66ae0, argc=argc@entry=1, argv=argv@entry=0x7fffffffdcb8) at driver.c:1265
%7 0x000055555559b8e2 in main_thread_handler (user_data=<synthetic pointer>) at driver.c:1402
%8 mono_main (argc=<optimized out>, argv=<optimized out>) at driver.c:2622
%9 0x000055555558b757 in mono_main_with_options (argv=<optimized out>, argc=<optimized out>) at main.c:52
%10 main (argc=<optimized out>, argv=<optimized out>) at main.c:434
```
Stepping into the crash handling machinery, the picture looks a bit different:
```
Thread 1 "mono-sgen" hit Breakpoint 1, altstack_handle_and_restore (ctx=0x7fffffffd2d0, obj=0x0, flags=0) at exceptions-amd64.c:871
871 {
(gdb) bt
%0 altstack_handle_and_restore (ctx=0x7fffffffd2d0, obj=0x0, flags=0) at exceptions-amd64.c:871
%1 0x00005555556957de in interp_exec_method_full (frame=0x555555c53f08, context=0x555555c38350, clause_args=0x0, error=0x555555c53f18) at interp/interp.c:4461
%2 0x0000000000000000 in ?? ()
```
So it looks like we messed up in the transition from altstack back to the program stack.
### The fix
The problem is that `backtrace` consults the unwind information emitted at the point where SIGSEGV happens in `interp_exec_method_full ()`. However at that given program code, there is no function call that allocates space to pass arguments on the stack. Still, we massage the stack to do that in the signal handler, which does not add up with the emitted unwind information by the C compiler.
Note that without the fix, crashing in `backtrace` is the worst case. In other cases we might (1) get still a correct stack trace, or (2) we get a wrong stack trace, and `backtrace` will not crash. So this PR might improve the crash experience overall.
This also reverts commit cff400f3fae9775ac734f8a691339e59a272872c.
|
|
* Aling alloca_size to 8.
* Prevent some false pinning in the monitor-resurrection.cs test when using the non-recursive interpreter.
* [runtime] Add a mono_compiler_barrier () function.
* Add a MONO_GET_SP opcode to pass to enter/exit_gc_safe_region, ldloca might not return a native stack address with the interpreter.
* Add an interpreter/gc callback to mark the interpreter stack.
* Copy only an integer in ENDFILTER.
* Add a native_stack_addr field to InterpFrame so the EH code has something to compare against native stack addresses.
* Add a FrameStack structure to allow allocation of InterpFrame structures and stack data outside the native stack.
* Allocate InterpFrames/stack data from a frame stack instead of the native stack.
* Make some calls non-recursive.
* Remove an assert.
* Use non-recursive calls in CALLVIRT_FAST as well.
* Fix stack size allocation for vararg calls.
* Add some micro optimizations to the calling code.
* Add more micro optimizations.
* [dtest] disable Crash test on interpreter
* Add some implicit conversions to STSFLD to fix a corefx test failure.
* Disable the new test.
|
|
* When we try to call a method to get the async_id to do an async debug and we are trying to do this in a generic method like this:
async Task<T> ExecuteAsync_Broken<T>()
{
await Task.Delay(2);
return default;
}
We need to inflate the generic type before call the method or we will get the error: Could not execute the method because the containing type 'System.Runtime.CompilerServices.AsyncTaskMethodBuilder1[T_REF]’, is not fully instantiated.
Fixes #17549
Fixes #17569
|
|
enabled (#17478)
* Removing all fixes to fix #15203 and #17083, and trying a new approach to fix this #17084, together.
The thing is when we are executing on hybrid suspend the caller is executed inside try catch in the runtime_invoke_ method that is generated. And this try catch should be ignored for the debugger exception, otherwise it's the last try catch in main thread, but should always be considered to generate the stack trace.
Fixes #17084
* This test check the case that we were missing. On preemptive this test always runs perfectly, on Hybrid, never run well until this PR.
* Changing how call unit test.
Changing variable name.
|
|
app (#17261)
* [sdks] properly shutdown runtime for Mono.Debugger.Soft test app
mini_jit_cleanup will cause mono_runtime_try_shutdown to be called before
mono_runtime_quit which will set the shutting down flags in the runtime.
* [test] Re-enable disabled tests
|
|
Running these tests makes the application crash, probably at shutdown. Even if the tests are reported as passing, check if disabling them fixes the suite timeout on android osx sdks.
|
|
* If there is a perform_wait_callback in the stack there will be another catch generated by the owner thread, so we don't need to throw, we can continue and find the next catch.
Fixes #17083
* Reverting unit test changed on commit 405d521.
* Fixing assert when calling mono_jit_info_get_method if it was a trampoline.
|
|
* Revert "[Mono.Debugger.Soft] Properly close connections"
This reverts commit 2da77073731dc88cfef40ed5a838e53896eca7d1.
This was previously reverted because it was causing issues and it still does. It is a hack fix. We signal the connection for closing and next we send the dispose command over the network. This is obviously racy.
* [Mono.Debugger.Soft] Make sure receiving thread always closes
When we want to close the connection, setting the close flag is not enough, because a thread can be already stuck in a blocking receive, without getting to check the flag. We fix this by additionaly breaking the connection, by using socket.Shutdown.
Fixes https://github.com/mono/mono/issues/7377
* Bump API snapshot submodule
|
|
* Creating a new version of MOD_KIND_EXCEPTION_ONLY to support VsWin features, discussed with Joaquin Jares.
Because we don't have this functionality of get every other exception that is not specified, VsWin was getting every exception and filtering later. But this causes a slowness during the debugger because we stop all thread on each exception that we get, even if they are caught and we don't want to stop.
* Fixing other unit test because now we have 2 nested classes.
Fixing indentation.
* Creating a flag in the MOD_KIND_EXCEPTION_ONLY protocol event and not creating a new protocol event.
* Changing what was suggested by Zoltan.
* Coding style
* Bump API snapshot submodule
|
|
compute_frame_info. (#15936)
[sdb][interp] Use the interpreter's resume state to compute the IL offset in compute_frame_info.
This recovers the relevant bits of the "resume state" from the interpreter and uses that to recalculate the `il_offset` for the top frame.
Fixes https://github.com/mono/mono/issues/15687.
|
|
* Bump api-doc-tools to latest master
Disable building mdoc.exe in mcs mode since it no longer builds because of new C# features.
* Fix mcs build by disabling more mdoc invocations
* Bump monodroid_tools to compile against v4.7 reference assemblies
mdoc needs ValueTuple which is not in v4.6.
* [csproj] Update project files
|
|
|
|
Implement debugger invoke when the this has an attribute that is a fixed size array.
Fixes #15556
|
|
|
|
Fixes #15268
|
|
* Fixes #13408
PR of draft https://github.com/mono/mono/pull/14667
* Disabling test on Interpreter.
|
|
* When the catch found is in a MONO_WRAPPER_RUNTIME_INVOKE the exception should be treated as an UNHANDLED by the debugger.
* Adding unit test.
* trying to fix side effect.
* I've tested the MonoTests.DebuggerTests.UnhandledException_2 test on VsWin using .net Framework and I think the test is wrong because the first break is in throw and the next break will be on breakpoint.
In our implementation we were ignoring the unhandled exception and stopping only on breakpoint.
|
|
This PR fixes #7377
|
|
* [sdb] Add property AssemblyMirror.HasDebugInfo
* Fix mono_debug_image_has_debug_info to work with ppdb
* Bump API snapshot submodule
|
|
|
|
They can be used with native line endings.
We now have a shared folder with the dotnet repos and they have CRLF normalization enabled.
This difference leads to conflicts while applying changes from the dotnet repos to mono.
|
|
* [android] Fix Mono.Debugger.Soft tests with Android SDKs
* [android] Fix connecting with LLDB
* [android] Add scaffolding to run profiler tests
* [android] Fix some corlib tests
* [android] Fix Mono.DebuggerTests.ExceptionFilter2
* [csproj] Update project files
|
|
It was recently reenabled in #9091 but it fails/hangs frequently.
|
|
* Fixed the Attach() test which required a free port to attach.
* Added test for incorrect events behavior when VM is started with suspend
* Bump API snapshot submodule
|
|
* [debugger] Reverting part of this commit https://github.com/mono/mono/pull/12114, removing this part the test ShouldCorrectlyStepOverOnExitFromArgsAfterStepInMethodParameter continues working and solve the regressions of 12881.
Inserted a new test that reproduces the regression.
Fixes #12881
|
|
* The version of the server and client should be bumped to call the elapsed_time.
* Removing extra {
* Calling correctly.
* This should be checked in ThreadMirror.ElapsedTime instead using vm.CheckProtocolVersion (), so calling the public method will fail.
|
|
value (#12394)
* [Debugger] Debugger failure when a method is called in watches and any field of the Class has the type of the field different of the value of the field because the assign was done in an unsafe way like this:
Now the datatypes check in the fields are only executed when it's not inside an invoke method.
_pinnable = Unsafe.As<Pinnable<T>>(array);
A unit test that reproduces the issue was created either.
Fixes #12374
|
|
enumerator. (#12368)
* [Debugger] Debugger crashes when inside a class, there is an internal struct, with a field that is an enumerator.
files.myBucket.GetEnumerator().get_Current().Key
Fixes #10735
* [Debugger] Debugger crashes when there is a generic struct with a field that is an enumerator.
Example: files.get_Current().Key
A unit test that reproduces this crash was added too.
Fixes #10735
* Removing the extra space.
|
|
Instead of deleting all, only delete the ones created by the test.
|
|
* Changing the test behavior as discussed with Ludovic, because we already have knowledge about the unreliability of the crash reporter and the test is not about it.
So if in 10 times at least one of them works for now it's good.
Fixes #11385
* Removing extra message.
* Removing the crash log file after the test is finished.
|
|
ShouldCorrectlyStepOverOnExitFromArgsAfterStepInMethodParameter (#12114)
The problem was in this line:
ss_nested_with_two_args(ss_nested_arg (), ss_nested_arg ());
The first step_into works correctly entering in the ss_nested_arg method, but the second one doesn't work.
The problem was because this flag MONO_SEQ_POINT_FLAG_NONEMPTY_STACK was set, so the debugger don't consider that it was a possible break.
The solution of the issue was create another flag to identify nested calls and ignore the MONO_SEQ_POINT_FLAG_NONEMPTY_STACK.
2 new tests were added to test other nested calls.
#Fixes 7326
|
|
|
|
* When going to https://jenkins.mono-project.com/job/test-mono-pull-request-arm64/8921/testReport/junit/(root)/DebuggerTests/StackTraceInNative/ for example, we have no idea why the underlying process has exited. To figure it out, we need to go to https://jenkins.mono-project.com/job/test-mono-pull-request-arm64/8921/parsed_console/log_content.html#WARNING1 and scroll back up to where the test was executed to find out the debuggee process crashed with an assertion.
This was fixed by redirecting the StandardOutput and StandardError of the debuggee process in the Mono.Debugger.Soft test suite.
* [Debugger] Record time it took between steps.
I implemented a new message to avoid breaking the protocol. I used the MonoStopwatch to count the time between the steps, it was already used in the debugger-agent.
Fixes #8460
* Bump API snapshot submodule
|
|
https://jenkins.mono-project.com/job/test-mono-pull-request-arm64/8921/testReport/junit/(root)/DebuggerTests/StackTraceInNative/ for example, we have no idea why the underlying process has exited. To figure it out, we need to go to https://jenkins.mono-project.com/job/test-mono-pull-request-arm64/8921/parsed_console/log_content.html#WARNING1 and scroll back up to where the test was executed to find out the debuggee process crashed with an assertion. (#12172)
This was fixed by redirecting the StandardOutput and StandardError of the debuggee process in the Mono.Debugger.Soft test suite.
|
|
protocol versions
|
|
* The problem with this flaky issue was the timing of processing of the async tasks, as it was executed in background threads it was not possible to reach the end of execution because all the foreground threads exit earlier.
The solution creates a TaskScheduler that ensure that the thread that will execute the task will be a foreground thread and then the test always works.
Fixes #6997
|
|
|
|
|
|
Use mono_mb_emit_op for CEE_LDOBJ to ensure wrapper data is added for
indirect load of a ref return value as method-to-ir expects this for wrappers.
|
|
|
|
duplication
|
|
(ThreadState.Stopped, e.Thread.ThreadState) (#11419)
Disable failing assert in failing test DebuggerTests.Threads Assert.AreEqual (ThreadState.Stopped, e.Thread.ThreadState)
https://github.com/mono/mono/issues/11416
|
|
|
|
|
|
This should help get information on native crashes that happen in hard-to-debug environments.
To quote https://github.com/mono/mono/issues/10157 :
When a mono runtime is attached to a managed debugger and the debugged runtime is induced to cause a crash, the state of that crash is not communicated to the managed debugger. This, combined with the difficulty in having the debugged runtime both attached to the managed debugger and lldb, makes this type of crash difficult to interactively debug.
When the managed debugger is the only connection someone has with the runtime because it is embedded in a way that is resistant to unmanaged debugging (watchOS application on-device, for instance), this is an even more difficult problem.
By adding an SDB protocol event that sends a type of "runtime death" and a blob of opaque json (version dependent, no protocol guarantees), people can report these crashes without having to assist a mono runtime engineer in observing a crash on device.
In the case that spurious bugs in this manner are submitted, it will require less effort as well to spot stack frames that indicate misuse of mixed managed-unmanaged APIs (which offer the ability to drive a segfault or g_assert
|
|
(#11229)
We only build it if we're explicitly building the monodroid profile and for the
monodroid_tools profile we only build the test assembly but not dtest-app.exe
|
|
And make it work for the monodroid_tools profile.
|
|
|
|
using a new SourceLink property on ModuleMirror objects.
Fixes https://github.com/mono/mono/issues/10038.
|
