I have a wxButton in my window which I'm binding with the following:
BitmapButton1->Bind(wxEVT_BUTTON, [=](wxCommandEvent& e)
{
if(TextCtrl1)
OptionsSizer->Detach(TextCtrl1);
if(Choice1)
OptionsSizer->Detach(Choice1);
if(BitmapButton1)
OptionsSizer->Detach(BitmapButton1);
if(TextCtrl1)
TextCtrl1->Destroy();
if(Choice1)
Choice1->Destroy();
if(BitmapButton1)
BitmapButton1->Destroy();
OptionsSizer->Layout();
OptionsWindow->SetSizer(OptionsSizer);
SendSizeEvent();
}, bId);
The idea is that when the button is clicked it deletes itself as well as a couple of other controls. The above however crashes. I've tried debugging but the debugger seems unable to pick up my breakpoints (something I've found common with wxWidgets).
After the lambda is executed the original pointers will be dangling, with incorrect, not-NULL values. Are they used anywhere else too?
In general, you'd need to provide more info for such a question, like more code, the stack trace, the type of build - you'd obviously need debug build in order to debug it, right?
the debugger seems unable to pick up my breakpoints (something I've found common with wxWidgets)
There is no such thing as wxWidgets preventing the debugger from hitting breakpoints in a debug build. Do make sure you are using the debug build - something I've found common with people with such issues.
Related
I swear I used to remember Visual Studio just breaking on an exception. It would take you straight to the line where the exception was thrown and allowed you to inspect variables just by hovering over them.
Or maybe that was a dream. Or maybe this is a nightmare.
But it's actually not a problem, right, because now instead of it just working all you need to do is go to Debug > Windows > Exception Settings where you get this mess.
Which has many glaring problems. For example:
Remember when I said it used to just work?
I don't have all these Exception types memorized.
Clicking toggle all on/off removes your previous selections.
Oh and also, clicking this checkbox does absolutely nothing
It used to just work. Is it possible to get it back to just doing that?
Under exception settings, Go to Common Language Runtime Exceptions->check all. This will not break your application, but show you the exact line of occurrence of the exception.
Per that first image you posted, it appears the application is throwing an exception in "external" code, so you likely have the "Just My Code" enabled in the debugging options. Try unchecking that "Just My Code" option via your Tools|Options dialog (Debugging\General category), and that'll likely fix you up.
I have an error in my form editor preventing me from modifying the form.
I know in which control this occurs but no way to find what exactly causes the problem.
I tried setting breakpoints in the InitializeComponents() of the form I try to open but it doesn't stop (I am in debug mode...). I also tried to attach using a second instant of Visual Studio as demonstrated here, but even when setting all debug exception options to "throw", the attached process doesn't stop and indicate anything about call stack nor other useful information...
All I know is that there is a disposed object I'm trying to access, but absolutely no information as to where in code, etc..
What could I possibly do to debug the situation - knowing which control is the cause but absolutely no idea as to which of the 300 lines of code causes the issue...
i coded a big project that runs when I open it in Debug or Release Mode, but when i open it without Debugging (ctrl + f5) it crashs. I searched a long time to find the heap error, but didnt find anything. The problem is i need the running .exe of the programm, so i wanted to ask if there is a possibility to link the windows debugger to the .exe so it always starts with it.
If it doesn't crash right away, maybe this helps:
You can run the executable.
Open your solution in visual studio. Make sure it's the same build.
Open the DEBUG menu and click attach to process.
A window will open, listing all processes that are running. Select the executable that's crashing
Click the DEBUG menu again and select Exceptions (ctrl-alt-E)
Make sure the checkbox "Thrown" is checked for Common Language Runtime Exceptions
Now crash your application.. It will halt at the line that causes it.
Also look for environment directives. like #IF DEBUG #END IF. or #IF RELEASE That kind of stuff. Tricked me a couple of times too..
Good luck. Hope this helps!
You can do various things. First make sure you have a "big out try block" in main. i.e. put the main logic in a try can catch exceptions and report these clearly. This probably isn't what's happening in your case.
You can attach a debugger - including Visual Studio, to a running process - see the "Attach to process" option under the debug menu. If it's built with debug symbols, which you can do, even for release code this may help. If it's optimised you may find it difficult though.
Finally, you could generate a crash dump and inspect that after it's failed. See docs on MiniDumpWriteDump. There are several examples on its usage. Or you can install an abort handler: See here. This mentions _set_abort_behavior which if invoked with _CALL_REPORTFAULT will generate a crash dump too.
I'm currently (trying) to develop an app with Worklight Studio 5.0.6 and Dojo (Mobile) 1.8.3. I have a really hard time to to find a proper method for debugging. After waiting 5-10 minutes for the build an deploy-process on the server, an error usually looks like this in the Chrome debugger:
How am I supposed to track down this error in MY source? The whole stack trace consists entirely of Dojo code which generates an absolutely useless error message after 20 abstraction layers.
Seriously, how do you guys handle this in real life? What methods do you use for debugging Dojo-driven apps in the browser?
spyro
For dojo.parse errors, I find it useful to pause the Chrome debugger on all exceptions (the purple icon on your screenshot, should be blue). You usally get more details about the cause of the error, the name of the DOM node being parsed, etc. in the first exception being raised.
Rémi.
Debugging dojo based application should be the same as debugging any javascript application.
Usually I will follow these steps:
add console.log() somewhere in code: this is fast and most of time this is enough.
set breakpoint in debugger: if step 1 is not enough, you can base on error information to set breakpoint before error line, then step in or step out.
comment out recently changes: for some error which is hard to find the error line, for example, parse error in your case, the good way is comment out your recently changes one by one till back to your last working version. Or, return to your last working version, then add code back one by one.
Create a simple application to reproduce the error : if your application is very complicate and it is hard for you to follow above methods, you can try to create a new application which mimics your current application but with simple logics and try to reproduce the error.
Based on experience : Some errors, for example, extra ',' in the end of array which works at chrome and firefox, will report a nonsense error information at IE. Debug these kinds of errors is very difficult, you can base on your experience or do a google search.
Did you provide isDebug: true in your dojoConfig? Also, try to see if the same occurs in other browsers.
Update: I recently discovered that there are issues with Google Chrome and Dojo debugging and I think it has to do with the asynchronous loading of files. As you can see in the provided screenshot of #spyro, the ReferenceError object is blank (which you can notice because of the empty brackets {}). If you want to solve that, reopen the console of Google Chrome, (for example by tapping F12 twice). After reopening the ReferenceError should not be empty anymore and now you can expand that object by using the arrow next to it and get a more detailed message about what failed.
Usually what I do in situations like that is to place a breakpoint inside the error callback (line 3398 in your case) and then look into the error variable ("e").
I am not sure how familiar you are with the Web Inspector, but once you hit the breakpoint open the Web Inspector 'console' and check for the error properties "e.message" and "e.stack" (just type in "e.message " in the console).
Also, during development it is better to avoid Dojo optimization / minification, which greatly improve your debug-ability.
Bottom line is to try to place the breakpoint before the error is thrown.
Basically my problem is that I expect Visual Studio (2010 Professional) to be able to evaluate any Visual C++ expression in the watch window that it handles in the code I'm debugging, but apparently there's something preventing this from happening. For example, when dealing with CStrings, evaluating the method IsEmpty on the CString in the watch window gives me a Member function not found error, as does a basic equality comparison (in the code being debugged obviously no problems).
Am I missing something here, or is what I'm asking for too much? Obvious solution would be to put debugging statements in my code for whatever CString operation I'm looking for, but I would prefer not to have to do this.
Update/Example:
CString blah = _T("blah");
Calling blah.IsEmpty() in my code works fine, but in the watch window of the debugger I get the error above (CXX0052). The contents of the variable blah can be seen the watch window.
I could reproduce your problem, and, indeed, the VS watch window shows Member function not found alongside with the error code CXX0052.
In the MSDN documentation I found that this problem arises due to a call of a inlined function, the CString::IsEmpty() member function is probably somehow inlined (this is what the Watch Window evaluator sees), to solve the problem, first open your project Configuration and disable inlining
Second, still in the project Configuration, choose Use MFC in a Static Library (somehow the Watch Window keep seeing the called function as an inlined one if you use it as shared library, maybe this is because in the Shared Library the code is inlined and the Watch Window evaluator don't use the Debug builds of such runtime libraries).
Third, clean and Rebuild your Solution.
After that, the problem should be fixed (remember to refresh the expression if you see the value grayed out in the watch panel) during debugging. Remember to switch back to your original Debug options or better, create a new Debug profile to keep this settings.