| Age | Commit message (Collapse) | Author |
|---|
|
|
|
* About HotReload now we can do in an android app and the debug will continue working:
1) add lines before the breakpoint and the breakpoint will continue working
2) remove lines before the breakpoint and the breakpoint will continue working
3) add new static methods
4) add new static fields
5) add new classes
Also we check what is supported by runtime to make it possible from debugger.
* Addressing @lewing comments.
* Fix wrong implementation.
* Changing enum as it was changed on runtime
* Addressing @nosami comments.
|
|
* Protect from null AsyncState when canceling the connection in VirtualMachineManager
Under some circumstances it could happen that the AsyncState is null because the socket connection was not established and the socket is therefore null.
This may happen when the debugger session has been started but the connection to the app didn't take place
* Added exception handling when canceling debugger connection on SoftDebuggerSession.EndLaunch
If any unexpected error occurs at this point, some important things may not happen like invoking the TargetExited event, which could cause the debugger session to hang
For this reason we should handle any exception happening here and report it accordingly
One reason for this problem to reproduce is when the debugger session launches but the connection with the app is not established, so the session will never end and potentially hang under any UI interaction
|
|
When the iOS simulator is stopped immediately after it starts up
the debugger would crash the IDE with a fatal unhandled null
reference exception in StartConnection.
An unhandled exception has occurred. Terminating Visual Studio? True
System.NullReferenceException: Object reference not set to an
instance of an object.
at Mono.Debugging.Soft.SoftDebuggerSession.<>c__DisplayClass47_0
.<StartConnection>b__0(IAsyncResult ar) in Mono.Debugging.Soft/
SoftDebuggerSession.cs:line 158
On stopping the simulator the startArgs field is set to null in
EndLaunch. This was not handled in the callback used in
StartConnection and would cause the fatal exception. Handle a null
startsArgs in the callback when checking if a retry is required.
Fixes VSTS #1506514 - VS crashes when start debugging Xamarin.Forms
(target iOS) project using iPhone simulator
|
|
|
|
|
|
|
|
|
|
|
|
Xamarin.Android has build tasks and tests that target net472 which won't
build without multitargeting Mono.Debugging.Soft.
|
|
Net6
|
|
|
|
https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1384996?src=WorkItemMention&src-action=artifact_link (#347)
|
|
For now, just removed some code that doesn't work
|
|
|
|
[Mono.Debugger.Soft] add ModuleMirror.ApplyChanges
[Mono.Debugging.Soft] add SoftDebuggerSession.ApplyChanges
Related mono/mono Mono.Debugger.Soft PR: mono/mono#20889
Related dotnet/runtime PR: dotnet/runtime#49043
Contributes to dotnet/runtime#44806
|
|
SDK style projects set the assembly version to 1.0.0.0 by
default. Classic projects use 0.0.0.0 as the assembly version.
Setting the version to 0.0.0.0 to avoid compatibility warnings.
|
|
|
|
|
|
|
|
|
|
|
|
Added options and events to support subprocess debugging.
Implemented experimental subprocess debugging for the Mono
soft debugger. This is done by intercepting calls to start
the debugger and injecting the debugger agent options.
This should ideally be handled by Mono itself, and we can
propose to incorporate the required hooks to Mono, but meanwhile
we can try this hacky implementation.
|
|
VS has UI to select what to output in the debugger. There's a very
common request from our users to filter the output in mono apps, which
is usually very verbose. This commits adds that in a way that's
performant and accurate. The runtime will still show some unneeded
output, but this first step enables fixing that in the future.
|
|
In Visual Studio it is possible to Load Symbols for existing assemblies. This functionality results in new assemblies being debuggable in the middle of the debug session. I'm adding this method so I can use this functionality, but also to be able to load symbols as assemblies are loaded and not all at the same time, which make the debugger more responsive.
|
|
This is an attempt to fix https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1109965/
Unfortunately, while this *does* improve things, it doesn't fix the
issue entirely.
|
|
[Mono.Debugging.Soft] Simplified breakpoint resolving logic
|
|
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1093441/
|
|
The old logic was trying to be so smart, it smartness-overloaded
into Smartness.MinValue.
In all seriousness, though, now that the IDE intelligently resolves
breakpoints to the correct line, we don't need to be "smart".
This code was only needed 10 years ago when the IDE would put
breakpoints on blank lines and so the debugger would need to
do insanely fuzzy matching. So fuzzy it needed glasses, apparently.
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1094719/
|
|
|
|
This reverts commit 2f5bb268a473d711605d1d391a75c3153ea1c7d4.
|
|
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1088095
|
|
With this fix it will probably work: https://github.com/mono/mono/pull/19317
|
|
* Implementing step through multithreaded code.
Fixes #14456
|
|
OnConnectionError
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1074174/
|
|
* Invalidating stack when calling abort of invoke method.
* Fix compilation error.
|
|
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/804257/
|
|
This reverts commit 8d2ae3125e9bedd2648619fc7b4b2641041fda9c.
|
|
mono/jstedfast-debugger-session-step-avoid-threadpool-queue
[DebuggerSession] Avoid using a dispatch queue for stepping
|
|
|
|
Catch InvalidStackFrameExceptions
|
|
Just have the backends asynchronously send the request to the
remote app/run time (SoftDebuggerSession already does this).
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/804257/
|
|
This reverts commit bb5d31bd1db5224b1f5f4315afa38ea23d615a44.
|
|
|
|
types that are passed by user and the ones that are already in the exception list, and we can receive some wrong information like a exceptionType = "test[" this is not possible to be parsed so we will get and INVALID_ARGUMENT exception, this PR is logging this information and ignoring the error, because this shouldn't stop the debug process.
|
|
Running VM with suspend="n" (for late attach scenarios), raise a number
of errors in debugger client. This is due to runtime not being suspended
for several events, but debugger client didn't check the suspend policy
returned by VM and always tried to do a resume triggering a
VMNotSuspendedException for several different event types.
Fix is to check the returned suspend policy (since that indicates if VM
is in a suspend state or not) and only resume when suspended.
|
|
|
|
In Visual Studio in Windows there is no concept of a Catchpoint. I'm exposing the Exception Event Requests so we can use them directly.
|
|
Partial fix for https://devdiv.visualstudio.com/DevDiv/_workitems/edit/901162/
|
|
|
