Since today, Qt Creator's debugger crashes whenever there is an error. Breakpoints no longer work either (the debugger doesn't crash but doesn't break into the code either). Any idea what could be causing this?
This is the error I get in the debugger window:
ModLoad: 6dd80000 6de04000 C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.7600.16661_none_ebfb56996c72aefc\comctl32.dll
sProcess exited (3221226519)
eProcess crashed
eCDB crashed
dNOTE: ENGINE SPONTANEOUS SHUTDOWN
dState changed BY FORCE from InferiorRunOk(11) to EngineShutdownOk(22).
dState changed from EngineShutdownOk(22) to DebuggerFinished(23).
dQUEUE: FINISH DEBUGGER
dNOTE: FINISH DEBUGGER
dHANDLE RUNCONTROL FINISHED
sDebugger finished.
Ok I got it. That's because I was working in release mode, so I guess the debugger was not available. Strange that it lets me start debugging though (the green arrow with the bug on it is not disabled) even though it's going to crash in case of error.
Related
I had hoped, updating would solve the problem, but still the debugger crashes at certain breakpoints. Some breakpoints seem to work, some make it crash.
If I mute breakpoints, everything works fine.
Please fix this, since it is very very annoying!
The following behaviour appears only on the mac versions of IntelliJ IDEA. First discovered it in version 2015, but in the currently newest 2017.1 it's still the same (both community/commercial).
set a breakpoint and start the application in debug mode (in my case a Spring Boot application started with application debug)
--> for the first time after server start the execution stops at the breakpoint (correct)
click "Run to cursor" and continue with the execution
execute the same to run again into the same breakpoint
--> the debugger does not stop anymore at the breakpoint (incorrect)
It also happens sometimes, that if the breakpoint is removed, the cursor still stops at the line, where the breakpoint was before.
After a server restart, everything goes fine again until the first execution.
Of course the code wasn`t changed in the meantime.
For these reasons, the debugger on mac is practically unusable.
Any ideas, if it's a bug (would be weird not having it fixed since years), or am I doing something wrong?
I have an issue in certain code only when built for "production".
This problem doesn't occur when in debug mode (Hitting the "Play" button to run the app).
So in order to debug this problem, I compiled the app and loaded to simulator. The problem does indeed reproduce as expected.
In XCode I can successfully attach to the running process by doing: Debug->Attach to process by PID or name" from my source code.
I am able to run commands in the LLDB console so I know that the debugger is connected to the app, but none of my breakpoints are working.
How is it possible to make the breakpoints work as expected in order to debug this issue?
I am trying to debug this Mono desktop software in Monodevelop.
I imported the SLN file, ran Build all with success, but when I press the Debug button I get this popup that stays waiting forever saying Waiting for debugger:
The output says:
User assembly '/home/nico/src/SparkleShare/SparkleShare/bin/SparkleShare.exe' is missing. Debugger will now debug all code, not just user code.
My first line of code is a Console.WriteLine whose output does not appear anywhere.
Am I doing something wrong?
Monodevelop 3.0.3.2 on Ubuntu 2012.10.
Nothing special appears on the console with monodevelop -v -v -v.
When I press Start Without Debugging instead of Start Debugging, the app crashes immediately saying The application exited with code: 255, but I need Debug to find where the problem is.
When I press Debug Application... and select bin/SparkleShare.exe, Monodevelop does nothing. The UI does not react in any way, it is like I pressed nothing.
When I run the application from command line, it runs fine (no crash), but Monodevelop does not react in any way, so I can't use it to debug:
mono --debug bin/SparkleShare.exe
Debugging in Monodevelop works fine with a solution created from scratch.
Here is a hack to debug in Monodevelop that works here, but it is quite painful, and unsupported.
Note: It is not the same problem as this question, which is about MonoTouch waiting for a phone simulator... the suggestions over there are about the simulator or updating XCode... no simulator nor XCode here.
MonoDevelop 2.8.6.3 is kinda old.
I recommend you upgrading to 3.x or even the master branch, which has a lot of improvements and probably fixes your issue.
please forgive the total newbie here - I am running an app in the simulator, and sometimes when it crashes it posts useful info in the console, other times absolutely nothing. When it posts nothing, what would be good steps to follow to start tracking down the cause of the crash?
First of all open the debugger after the crash and look at the stacktrace.
In addition to that you could enable NSZombieEnabled for the executable when those vague bad access errors show up.
Debugger with stacktrace(top left window), XCode3
Stacktrace Xcode4
I can continuously reproduce this kind of behavior with our app. It uses ARC so im pretty sure nothing gets over released, and we have zombies enabled. Xcode will say "Paused" instead of displaying a list of threads, the "Continue" button is active, but doesn't do anything, and entering bt on the (gdb) prompt says No stack.
This is driving me crazy!
Determine on what event the app is crashing. For exapmple if the app is crashing on the click of a UIButton, you can put a breakpoint on the action and step through code lines to see on which line the crash happens. Sometimes when there is no crash log on the crash of app, debugging through this method, does prove to be helpful.
I suppose this is a memory issue.
sometimes it happens to me as well.. the app crashes without any error message getting posted in the logs.. 95% of the time it is because I would be not be releasing something or would be releasing something and accessing it( which would usually create a log)... go through your code and see whether you are releasing properly and using autorelease option where needed...