i´m currently developing a debugger for Mono. Therefore I am using the Mono.Debugger.Soft.dll which has the VirtualMachineManager and VirtualMachine.
The question is: If I want to create a breakpoint in a simple program, how can i do this?
(E.g. Sourceodefile: Program.cs and Line: 17)
The Instance of VirtualMachine has a SetBreakpoint-Method, but this Method wants a MethodMirror. It is not clear for me how i can obtain this with knowing only the location within the sourcecode-File?
greets
Christian
What you have to do is listen for TypeLoad events. When you get a TypeLoad event, iterate over all of the MethodMirrors in the TypeMirror looking for a matching filename and line number.
If you find a match, then you can set a breakpoint on that MethodMirror at the ILOffset.
However, if the program has already started running, you may have a problem in that you may have missed the TypeLoad event for the Type that the method exists in. The solution to that is to keep a cache of all loaded TypeMirrors from the very start of debugging the program so that you can also iterate over types that have been loaded before the user tries to add said breakpoint.
You may be interested to know that a command-line debugger is already in development: https://github.com/mono/sdb
Related
I'm trying to port my console app over to a Blazor app. Everything worked fine inside the console type project, but it's not inside the Blazor project so I'm trying to troubleshoot. The app calls some things from a separate "class library" type project within the same solution.
The troubleshooting process itself is having issues of its own though. After a little bit of confusion I realized that the breakpoints set inside the referenced class library type project's code are not being hit.
Checking to console, I see it gives the error:
L: Unable to insert breakpoint at FtxApi.FtxWebSocketApi/<Test>d__5:MoveNext ():15
Is there anything I need to do (project settings or something) for the debugger to hit these? Or is it not supported at the moment?
Right now I'm just using a lot of Console.Writeline sort of as a workaround/replacement. And I noticed that the Console.Writelines inside the referenced class library type project are being called.. but only up to a certain method call that comes from a third party package. Execution seems to return from that point (nothing is called after it). Not sure what's going wrong there - more troubleshooting is needed, which brings us back to the breakpoints not firing (ideally I'd be able to make use of them).
I understand Blazor is new (and I'm an absolute beginner at using it), so not everything needs or is going to be perfect. I'm asking about the breakpoints kind of out of curiosity (I'd like to get them working but no big deal otherwise).
What I'd really like some insight into is: What might be going on with the code seemingly stopping execution / returning at that one particular method call? The method I'm calling is WebSocket.Open(), from the package WebSocket4Net. As mentioned above, I've tested this before (in a Console app) and it worked fine, so I'm guessing it's somehow related to Blazor which I'm unfamiliar with. I'm unsure how to get any more info to help debug this problem. Any help appreciated.
Edit:
I managed to find a solution to my problem without the use of debugging tools like breakpoints and such (I just used Console.Writeline a lot). I guess Blazor does not support some websocket implementations or something, because I found this error: System.PlatformNotSupportedException: Operation is not supported on this platform. blazor.webassembly.js:1 at System.Net.Sockets.Socket coming from websocket.Open(). I managed to get it working by implementing System.Net.Websockets instead, similar to this. Though my troubleshooting is over (for now), I'm still wondering if it's somehow possible to use breakpoints inside other referenced projects.
There are 2 solutions:
Solution 1: Right-click at Solution, choose Properties, choose Common Properties, Choose Multiple startup project, choose Action Start for Foo.Client, Foo.Server, Foo.Shared . Something like this
See https://blog.magnetismsolutions.com/blog/paulnieuwelaar/2015/04/07/debug-multiple-projects-at-the-same-time-in-visual-studio
Solution 2: Compile SharedProject, attacht PDB for debugging.
https://learn.microsoft.com/en-us/visualstudio/debugger/how-to-debug-an-executable-not-part-of-a-visual-studio-solution?view=vs-2019
I'm developing a frontend of LLVM IR, and want to attach debug information. I already made the %llvm.dbg.declare works, it can track my variable after this declaration. But I do not understand the another %llvm.dbg.value's purpose, can anyone tell me what situation I should use it? or any examples?
llvm.dbg.declare is sufficient if you're building your code without optimizations (which you should really do). In non-optimized code, locals live on the stack (in allocas) and llvm.dbg.declare tells the debugger where to find them
When trying to debug optimized code, things get murkier because locals can be in registers and there's no actual "memory location" the debugger can examine to always know the value of a local. This is where llvm.dbg.value comes in - it can explicitly notify the debugger that a local has changed, and its new value.
Can I set the Visual Studio debugger to break on thread creation?
(Note this is not the same as breaking on context switch as asked for in this other question: Can I set a breakpoint in Visual Studio (c++) to break on a thread context switch?)
I've found a way to do it. While googling I saw the opposite question:
Is it possible to break on thread exit with specific error code?
I put a breakpoint at the function RtlExitUserThread, after that I realized that all threads was creating with the function RtlUserThreadStart, so put another breakpoint to that function and that's all :)
As explained by #George, there are two functions you can break on. If you want to find out what creates the new thread you should break on thread creating WINAPI function calls such as CreateThread or _beginthread(ex). If you want to break into the start of the newly created thread (on the call stack of that thread itself) you should break into RtlUserThreadStart.
However, there are two prerequisites to be able to break into either of these:
1. Symbol downloading from Microsoft Servers needs to be enabled
For the breakpoints to work the debugger needs to know some basic symbol information of the native dlls. Make sure symbol loading from MS servers is enabled (Tools -> Options -> Debugging -> Symbols)
2. You need the actual stdcall signatures of the target functions
For some reason even with enabled export loading VS was unable to find the functions I needed to break on for me. So I went checking what the actual signatures are. This can be done by using the dumpbin cmd line tool of VS, or by running a short test on the code:
void* ptr = CreateThread;
Running this code in the debugger reveals the address and signature of the CreateThread for example which is _CreateThreadStub#24 for me (Win7 32-bit application). For RtlUserThreadStart it was ___RtlUserThreadStart#8 for me.
3. Setting the breakpoint
Now it's as easy as choosing Debug -> New Breakpoint -> Break at Function. For the function name you put either _CreateThreadStub#24 or ___RtlUserThreadStart#8 and leave the rest be.
This then triggers when a new thread is being created.
Observation
_CreateThreadStub#24 seems to cover the CreateThread, _beginthread and _beginthreadex functions.
If you know the thread is being created by the managed Thread class, then a simple solution would be to put a breakpoint on its entry (by going to the Breakpoints window, clicking New->Break at function and marking Thread.Start).
Otherwise, as Hans said, you would have to use a more complex solution like mdbg, or using a open-source implementation of CLR profiler (like SAE) and putting an "asm int 3" instruction in the ICorProfilerCallback::ThreadCreated method.
Also, if you have VS2010 Ultimate, you could just look up the Thread Created event in Intellitrace events, and possibly get the information you need from there (though this will not break when the thread is created, but rather give you some info about the stack trace/variable values at the time it was created, in retrospect).
Yes, the debugger gets a notification for it. No, the UI doesn't allow you to tell it to break on that notification. If this is for managed code then you could use the MDbg sample and modify it.
There are at least 2 potential things you could mean when you say you want to break on thread creation:
Break inside the creating thread BEFORE the new thread has been created
Break inside the NEW thread before the user-provided function is called.
For the first option, you'll want to break in CreateThread, _beginthread, or _beginthreadex.
For the second option, you'll want to break in RtlUserThreadStart or BaseThreadInitThunk to catch the new thread early in its execution before user code gets called.
Unfortunately, Visual studio won't break in those functions if you create a breakpoint with the function names I've listed above, at least not by default. The problem is that for native debugging, it doesn't load DLL exports by default, and without that, the debugger has no idea where to find the names I've provided above.
Before you start debugging, in Visual Studio go to tools, options, debugging, then expand the debugging options tree in the left pane. Then click on "native" and check "Load DLL Exports". Then you can start debugging your executable again.
After that, you should be able to create a breakpoint on any of the functions I mentioned by typing in the name. You may or may not need to specify the DLL the function is in by creating the breakpoint with the name as follows:
{,,kernel32.dll}CreateThread
or
{,,ntdll.dll}RtlUserThreadStart
I got this information by starting here:
https://blogs.msdn.microsoft.com/reiley/2011/07/26/debugging-tips-for-multi-threaded-application/
and doing some experimenting on my own. I know this is a response to an old question but I hope this saves other people some of the pain I've had when trying to debug crashes that happen immediately upon thread startup.
You can set a breakpoint at the first call to CreateThread (maybe you insert a fake call for this purpose).
When hit, change from Source Code View to Disassemly View and step into the call. Go through the ImportLib-Code and set a breakpoint. Not perfect, but it works.
I have been tracing a BAD_ACCESS error using NSZombieEnabled. As error I get returned:
*** -[MyDocument respondsToSelector:]: message sent to deallocated instance 0x2671b0
I do know what this means,however what surprises me is that I don't call this function anywhere, not in MyDocument.m nor in any imported files.To be exact, I don't call this at all in my whole project. The debugger will not go to the actual code that causes the error, but only shows the assembly code, which, when I click on it, gives me and even bigger list of not understandable numbers.
Does anyone have an idea where this weird "respondsToSelector" could come from? Maybe from frameworks I am using? I am really confused.
Thanks for any help!
respondsToSelector: is widely used in frameworks. For instance, if your class is a delegate or data source (highly likely for MyDocument) the delegating object will use it to determine which delegate methods you support.
In general, the way to find out where a problem like this is happening is to set a breakpoint on objc_exception_throw() (Run->Show->Breakpoints, double-click where it says “Double-Click for Symbol”, type objc_exception_throw) and run under the debugger (Build->Build and Debug - Breakpoints On).
I have some code which generates a large quantity of ArgumentExceptions on one particular line (which is in a different developer's code, so I can't just change it), which are then caught and handled appropriately.
I'm trying to debug ArgumentExceptions which are happening in a different section of code (and are then caught and handled, so I can't just look at unhandled exceptions).
Is there some way to ignore the ArgumentExceptions originating from that particular other line of code, while still breaking on ArgumentExceptions which are thrown elsewhere?
You might be able to do this, but it depends on how the code you want to debug is located relative to the other developer's code, and whether or not you can modify (but not commit your changes) to his code.
The first thing you'll want to do is, at least temporarily, go to menu Tools -> Options -> Debugging in Visual Studio, and tick the "Just My Code" box. I assume this is available even in Express editions, but it may not be, and if it's not available for you I'm afraid the rest of what I have to say probably won't help.
Anyway, once you have that ticked, you will no longer see break-on-throw notifications for code that isn't "yours." This means code that is from an assembly not in your .sln, or code marked with the [DebuggerNonUserCode] attribute from System.Diagnostics. What I usually do then is temporarily decorate the offending methods with [DebuggerNonUserCode] until I'm done debugging what I need to debug, and then revert those changes before checking in to souce control.
It's not as elegant as I'd like (I'd love a "never break on throws from this site again" checkbox in the exception assistant), but it's better than nothing.
I believe there may be other debugger settings that could interact with how "Just My Code" works, so if this doesn't work for you let me know and I'll try to get a more accurate picture of what my settings look like when I do this.
If you are talking about the "Break On Throw" exception feature then no there is not. It is strictly a type based feature only and does not have any way to control for what section of the code throws the exception.
Your best bet is to just place breakpoints on all of the lines which throw or temporarily suspend throwing an exception from the one place that you care about.
If you know how you are calling it, I would set the break point in your code and then step into (F11) from there. You could also smack the programmer until they fix their code, which would have the effect of making you feel better (unless you are a pacifist) and maybe they won't have so many ArgumentExceptions in their code (which would probably make you feel better even if you are a pacifist).
Sounds like using exceptions as flow control. If the one you're trying to debug occurs later in the program, you can try to attach the debugger later, or you can wait until after the program is running to turn on breaking when an ArgumentException is thrown.
Try to limit the scope as well - if the exception you're interested in derives from but is not exactly ArgumentException, break on that one instead.
Tell the other developer to fix his code.
Edit: In .NET 4, you can attach a handler to the AppDomain.FirstChanceException event, filter out non-ArgumentException excepitons and filter out the bad one based on the call stack.
The links in the comments are great.
i think Conditional Breakpoints are what you're looking for here. You can do this by right clicking your breakpoint and clicking the Condition... menu item.