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).
Related
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
Context
I'm trying to implement a sort-of orchestrator pattern for our applications.
Basically, we have three different and independent applications developped in Qt that communicate with each other using Web Socket. We'll call them "core", "business" and "ui". This is a flexibility aim as we can simply develop a new application in a more suiting technology and connect it to the others via the same communication protocole.
Now the idea is to have a simple launcher that allows us to specify which part to start. We launch this "orchestrator-like" application and it starts all required processes from a configuration file.
Everything is done in Qt currently (QML for the UI interfaces).
Initial Issue
I've made a custom class oriented towards reading the configuration file, preparing the processes, and starting them with their respective arguments.
This uses a std::map of QProcess related to their name in the configuration file and launch them using QProcess::start(<process_path>) method.
The catch is that everything went smoothly until recently. The sub processes are started and runs perfectly ; everything goes on as normal until we reach some point were the "ui" part crashes (usually an LLVM memory error or vector:: length error).
At first we thought about a memory leak or a code error but after much debugging we found that the application had no error whatsoever when we ran each part individually (without using the custom orchestrator class).
Question / Concerns
So, our question is: could it be that the QProcess:start() method actually shares the same stack with its parent? Three processes having the same parent, it would not be surprising than a vector of ~500 elements stored in each application can exceed the stack size when returned.
Information
We use MacOS Big Sur, IDE is Qt Creator, using Qt 5.15.0 and C++11.
Tried using valgrind but as read here and here, this seems a dead-end for now. The errors below were seen in the .crash file following the application exit.
libc++abi: terminating with uncaught exception of type std::length_error: vector
ui(2503,0x108215e00) malloc: can't allocate region :*** mach_vm_map(size=140280206704640, flags: 100) failed (error code=3) ui(2503,0x108215e00) malloc: *** set a breakpoint in malloc_error_break to debug LLVM ERROR: out of memory
Also tried to redirects or completly remove the application's output. First changing the setProcessChannelMode when starting the application, then with startDetached instead of start. Then, commented my Log method dumping log info into the corresponding Qt output (info/warning/critical/fatal/debug).
As suggested by #stanislav888, we could rewrite the application manager part in bash scripts and it would probably do the trick but I'd like to understand the root issue to avoid future mistakes.
It looks like a bad design. Application running and orchestrating through bash or PowerShell script looks much more better.
But anyway.
You could try to suppress orchestrated applications output and see what happen. The programs output might flood memory and make crash.
You must check what particular trouble cause the crash. Use memory "coredump" and system error messages to understand the all problem details.
I sure the community need that details. Because "оut of memory", "stack depth exceeded" and same errors make big difference.
Try to write bash or PowerShell script which does the same workflow as the Qt application. Hope it is not hard. But it will help you to figure out the issue.
At least you can run this script from the application.
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 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
A lot of time can pass between the moment a stack trace is generated and the moment the stack trace is thoroughly investigated. During that time, a lot can happen to the file in question, sometimes obscuring the original error. The error might have been fixed in the meantime (overlapping bugs).
Is it possible to get Stacktraces that show the offending file at the time of the error?
Not elegantly, and you normally don't want the user browsing through code that's throwing unexpected exceptions anyway (open door to an attacker).
Usually, what happens in a dev shop is that the user reports an error, stack trace, and the build it occurred on. As a tester, you can grab that build from your archives (you ARE keeping an archive of all supported releases somewhere handy, RIGHT?), install, run, and try to reproduce the error, working with the user to provide additional info as necessary. I've seen very few bugs that couldn't be reproduced EVENTUALLY, even if it required running the program against a backup of the user's production database to do it.
As a developer, you can download that build's source code from your version control repository (you ARE using version control, RIGHT?), and examine the lines in the stack trace to try to discover the problem by inspection, and/or build and run it to reproduce the error. Then, you go back to the latest source version, build, and run the same steps (a UI automation system can help out here), and if you don't get the error, someone else already found and fixed it. If you still get the error, you also got an updated stack trace with lines that match the current build, allowing you to set your breakpoints and step through.
What KeithS said, plus there are ways to capture more helpful state information at the time of the Exception using the Exception.Data property. See http://blog.abodit.com/2010/03/using-exception-data-to-add-additional-information-to-an-exception/
While KeithS' answer as pretty much correct, it can be easier and more elegant than you think. If you can collect a dumpfile (instead of just a stack trace), you can use a Symbol Server and Source Server in combination with your debugger to automatically pull your correct-version code from source control.
For example: if you enable PDB output and source-server integration in MSBuild, and upload the resulting PDBs to a symbol server, Visual Studio can automatically load the correct source control from a TFS or SourceSafe repository based on the information in a minidump.