During my debugging of code, facing one issue regarding Reset. In debug mode, whenever I am putting breakpoint, after getting hit and clicking on Run (Command), getting Software Reset. This is not occurring, when I am not putting any breakpoint in the code, software runs normally. Also after breakpoint got hit, if I execute software via Step command, then also I am not getting Reset.
As the code Size is very Huge, exactly not getting, where is the problem.
I want to know which line of code getting executed, before reset function is called ?
Is any one knows the answer, they can help me.
Using below environments:
Microcontroller: NXP
Debugger: J-Link
Debugging Software: Ozone Debugger
Related
I'm working on an embedded Linux application in Qt and am running into SIGSEGV problems that I'm unable to trace. I'd love to be able to post code but Qt Creator only shows me some assembly code and doesn't provide much of a stack to trace back through.
I can see that the crash happens in QApplicationPrivate::notify_helper(QObject*, QEvent*) after an attempt to branch to an invalid address. I can see that this was called by QApplication::notify() but that's all the stack information Qt Creator gives me. The only thing I can think of at this point is that previous segmentation faults looked like they had something to do with killing a QTimer (many of the timers I'm using are single shot) but I was dumped into the disassembly and could never determine which QTimer was causing the issue. That crash was sporadic while this one seems to be pretty consistent.
Can anyone suggest what I might be able to do to get some more information to allow me to track down the source of this fault? I can provide additional details as needed, though I might need to know where I should even be looking.
EDIT:
It turns out the cause of the previous error was an array index that wasn't properly bounds checked. I still occasionally see a crash that appears to be related to a QTimer as the disassembly points to QObject::startTimer(int) but I can't see any obvious cause in this case. Again, the stack provides no insight into which timer may be causing the problem; I can only see a call to QTimer::start() followed by QObject:startTimer(int).
A Qt project gives a number of errors - that I do not actually consider errors I think:
Some examples:
Fontconfig error: "/etc/fonts/conf.d/65-khmer.conf", line 32: out of memory
// ?
QGraphicsItem::ungrabMouse: not a mouse grabber
// i think happens when the mouse grab didn't quite happen, user moved too fast...
A few others
the first one seems it has an answer here https://askubuntu.com/questions/421891/fontconfig-error-out-of-memory
So I cannot fix it through software, the user must fix it... since it is system dependent...
Even built in release, these errors will still show up on command line... Since they do not cause the application to behave abnormally, I don't think the user should see them.
How can I build/deploy the application without these errors showing ?
ideally of course there would be no errors in a deployed application, but I don't know what I can do about those types of errors...
It is possible to redirect a stream (in this case stderr) after the fact using
freopen("/dev/null", "w", stderr);
Just place this in your main before any other code runs and you should be good. Keep in mind that this might need more work on Windows.
If the error message is posted through the Qt Message infrastructure (qDebug etc.) you can set a new message handler through the function qInstallMsgHandler.
I'm debugging some of my code on Visual Studio. This code belongs to a custom Session Provider that I created, and I'm debugging it on my web application launch. It starts initializing my provider, and on that function I have a breakpoint that is being hit successfully the first time. However, that same breakpoint is being hit again, but it has a small blue icon and if you hover over, this message is displayed:
The process or thread has changed since last step
On my research I've found several kinds of answers, from people saying that the breakpoint is hitting a different assembly to some others saying that the breakpoint has been hit from a different thread.
Does anybody know what does this really mean?
When you have multiple threads running the same piece of code and you have a breakpoint there, Visual Studio will stop the execution every time any of those threads hit the breakpoint.
This will happen for every thread, in an unpredictable order.
When you are debugging step by step on your code, another thread can execute the code that you were debugging and hit the breakpoint. Visual Studio will let you know about this by putting that blue circle with the exclamation mark on the next statement arrow.
See more here: Debug Multithreaded Applications in Visual Studio
This icon simply means the breakpoint was hit on a different thread than the last thread you were on. It doesn't affect the program behavior at all.
I get an EXC_BAD_ACCESS error at a place that doesn't have anything to do with the root cause. I fortunately found the reason to be an array that was too small for the following statement [data getBytes:&tcpBuffer length:i];.
Now my question: I tried all these theree methods - but without success:
Using NSZombiesEnabled did not change anything in the debug window printout
When I set the scheme to debug and to use Leaks instrument it starts the leaks instruments but I don't see the debugger.
When I just run the app in iPhone Simulator and the start Instruments separately, selecting the running app as a target (in the pop-up-menu in Instruments) it stops with an error saying something like "couldn't find the target ".
How does one find the root cause in cases like that? Keep in mind, at the end, it wasn't even a Zombie error! This error message is REALLY more confusing than helpful!
(luckily I just thought of my array, but surely, the next time this will haunt me somewhere else)
It's quite likely that the place you get the EXC_BAD_ACCESS will not be related to the root cause. It could be related and could therefore offer a clue. But that's not certain.
To answer your points:
NSZombiesEnabled will only have an effect if you invoke a method on an object that has been deallocated. That might not be the cause of your EXC_BAD_ACCESS.
Using Instruments is separate to the debugger. If you profile in Instruments, the debugger is not active. Basically, it's a different tool.
This should be ok. Check that your Build Configuration is set to "Debug" and not "Release".
Here's a great link on what causes EXC_BAD_ACCESS and how to track down the root problem:
Lou Franco's Understanding EXC_BAD_ACCESS
On my work computer, debugging in Visual Studio 2008 (SP1) seems to work somewhat different from what I'm used to. I have two problems that might or might not be related.
First problem:
When I'm running a web application in debug mode, and an unhandled exception occurs, I get a Yellow Screen of Death immediately. Normally my code just breaks at the line throwing the exception, allowing me to inspect the state of the program.
For some reason, the only way I can do that on my work PC is to set a breakpoint on the line that threw the exception, and repeat what I did. It's been annoying me for a couple of days now, but I have no idea what could cause this. Any ideas?
Second problem
The WCF webservices used in the site I'm debugging behave a little odd when it comes to debugging as well. Most of the time, setting a breakpoint in the service won't have any effect when it executes that code. At first, I figured I had to attach to the wcfhost process, but that isn't it. When I put a breakpoint on the line where it calls the service, and use F11 to step into the method call, I do end up in the service's code and I can debug all I want.
Why would stepping into work, while breakpoints get ignored? Is there a way to change this behavior?
For the 1st problem:
In Visual Studio go to Debug/Exceptions
You should see three columns in the list: "Name" (type of exceptions), "Thrown", "User-handled"
In the "User-handled" column you have to activate the checkbox for "Common Language Runtime Exceptions".
Note, if you shouldn't see the "User-handled" column, go to Tools/Options, then click on "Debugging" in the tree and on the list activate "Enable Just My Code (Managed only)". Then the column "User-handled" should be visible in the other dialog and you can activate the according checkbox.
For the 2nd problem:
It seems to me as if I have experienced a similar problem. I guess you have to set the breakpoint there, because the WCF service runs on a separate "webserver" (your local VS webserver). Therefore it isn't like a normal method call within your same application and therefore you have to set the breakpoint on the WCF method that gets called. I always did it this way and it worked perfectly for me.