Unsolved Access violation by button click due to long running process
-
Hello, sorry for the potentially weird question but that's all I have for these kinds of forums these days it seems.
Essentially though what is happening is that my program is crashing for processing certain files on a button click. It does not crash on smaller files but on large ones that could take up to an hour to process it will eventually crash. The cause of the crash seems to be caused by a access violation caused by the "QAbstractButton" clicked signal. Specifically it's when "QMetaObject::activate" tries to handle the clicked signal. This is after running for upwards of an hour.
Unfortunately I can't show any code as it is proprietary but I can tell you that the version of QT I am using is 4.8.6 and the debugger I am using is Visual Studio 2012. I am running the debugger with the debugger attached in release mode as debug mode would take ages to process this data.
I guess my question boils down to, is this access violation caused because I'm blocking the QT thread for too long and that is causing it to crash?
I am doing part of the process asynchronously but another step after that needs to be done synchronously and it seems the program crash on that step. Do I have to tell QT to process events explicitly during my long running process?
-
Hi @meursault, and welcome.
@meursault said in Access violation by button click due to long running process:
I guess my question boils down to, is this access violation caused because I'm blocking the QT thread for too long and that is causing it to crash?
You are allowed to block any thread for as long as you want. Blocked threads should not crash (although they become unresponsive).
An "access violation" means your program is trying to read/write a part of memory that it's not allowed to touch. Some common causes include:
- Using an out-of-range index in an array
- Dereferencing a pointer that has already been deleted
Unfortunately I can't show any code as it is proprietary but I can tell you that the version of QT I am using is 4.8.6 and the debugger I am using is Visual Studio 2012. I am running the debugger with the debugger attached in release mode as debug mode would take ages to process this data.
I recommend running it in Debug mode overnight. If it takes ages, so be it.
The debuggable stack trace will be invaluable to you.
-
@meursault
I was about to write about the same as @JKSH . If you compile for debug and run from debug inside a debugger, but don't place any breaks or watches, it usually should not take that much longer than non-debug code. Then hopefully you get a stracktrace/context for the crash. -
Thanks for the reply. I am running it in debug mode now.
I did run it in release mode with the visual studio debugger attached but of course that doesn't generate the whole pdb mapping and such. But I did get a call stack on the crash that did show me that it was indeed an access violation caused by QT handling a clicked signal.
Am I just not seeing the full picture somehow and this access violation caused by a QT clicked event is actually caused by something else?
I wouldn't be surprised but normally when I run in release with a debugger attached it shows me somewhat useful information when it crashes. I'm sure this is not as reliable for debug information but I would just like to know next time I encounter a weird crash that says it's being caused by QT.
-
@meursault said in Access violation by button click due to long running process:
I did get a call stack on the crash that did show me that it was indeed an access violation caused by QT handling a clicked signal.
Are you allowed to post the full stack trace? Change the names of your application's functions to preserve confidentiality, but don't change the structure.
Also, compare the Release mode stack trace with the Debug mode stack trace -- do you notice anything unusual?
Am I just not seeing the full picture somehow and this access violation caused by a QT clicked event is actually caused by something else?
I'm sure that the debugger isn't lying when it says that the access violation occurs at the instant when
QMetaObject::activate
is called. But we don't know whether it's QMetaObject's fault or not.Think about the button and the signal. Is it always the same button that causes the crash, or do different buttons cause it? Look at the signal parameters -- are they deletable? Are they custom types? Look at the slot(s) connected to those buttons -- does the receiver object get deleted at any point?
Also, which thread processes the file -- your GUI thread, or a secondary thread?
Does the problem still exist if you build your code against Qt 4.8.7 (the last version in the Qt 4 series)
I wouldn't be surprised but normally when I run in release with a debugger attached it shows me somewhat useful information when it crashes. I'm sure this is not as reliable for debug information but I would just like to know next time I encounter a weird crash that says it's being caused by QT.
That's the nature of bugs: We know how the system is supposed to behave, but since it is misbehaving we can't make any assumptions on what's going on. So, the most systematic way forward is to gather as much detailed evidence as feasible. It could be a bug in your code; it could be a bug in Qt's code.
You might even encounter a Heisenbug where the program's behaviour changes when you run it in Debug mode. This could either frustrate you to no end, or it could provide a different set of clues to help you track down the bug.