I have recently experienced exit code 255 in my Qt 5.7 application. This happened right after I added my custom QGestureRecognizer. I have debugged into the Qt's sources and I came to the conclusion that the QGestureManager automatically disposes of all QGestureRecognizer instances. The line that causes the issue is inside the destructor of widget where the recognizer is created and registered:
Demo::~Demo() {
// delete other stuff
delete recognizer;
}
The thing is QGestureRecognizer doesn't support (at least according to the documentation and by looking at the constructor's signature) the parent-child relationship in Qt since it's not derived from QObject (or any subclass of that fundamental Qt class). This means that one cannot assign a parent to the its constructor hence QCustomGestureRecognizer recognizer = new QCustomGestureRecognizer (this) isn't possible. Continuing this line of thought this means that one has to manually trigger the destructor by calling delete recognizer. Or so I thought...
At the end of the life of my application the QGestureManager is called. In there there is a list of recognizers called m_recognizers. It contains a bunch of the built-in recognizers (such as the one for the Tap gesture) along with the registered custom recognizer (in my case it was registered as 257). The destructor of QGestureManager iterates through the list and deletes its entries.
When the delete recognizer line is present I get a segmentation fault when qDeleteAll(...) (for the m_recognizers) reaches the custom recognizer's entry since it attempts to delete something that has already been deleted.
After I commented out the delete recognizer line in my widget's destructor I no longer face the issue however I'm still uncertain if I'm not breaking my code somewhere. The exit code is not (as expected) a 0 but the information on how recognizers are disposed is completely missing from the official documentation.
Has anyone encountered this problem? I'm not excluding the possibility that the issue arises from some other part of my code although it seems quite unlikely considering that it appears when the default QWidget destructor is called. As per C++ standard when inheriting a class first the subclass' destructor is called (in my case this is the Demo custom widget - no issues there) and then the base class.
If you use
Qt::GestureType QGestureRecognizer::registerRecognizer(QGestureRecognizer *recognizer)
the System does take ownership of the object and you should not delete it yourself.
Excerpt from the Documentation:
The application takes ownership of the recognizer and returns the
gesture type ID associated with it.
Related
Was passed a set of rendering library that is coded with OSG library and run on Window Environment.
In my program, the renderer exists as a member object in my base class in C++. In my class initiation function, I would do all the neccessary steps to initialize the renderer and use the function this renderer class provide accordingly.
However, I have tried to delete my base class, I presumed the renderer member object would be destroyed along with it. However, when I created another instance of the class, the program would crash when I try to access the rendering function within the renderer.
Have enquired about some opinions on this matter and was told that in Windows, upon deleting the class, the renderer would need to release its glContext and this might be indeterminant time in Windows environment pending upon hardware setup
Is this so? If so, what steps could I take beside amending the rendering source code(if I could get it) to resolve the issue?
Thanks
Actually not deleting / releasing the OpenGL context will just create some memory leak but nothing more. Leaving the OpenGL context around should not cause a crash. In fact crashes like yours are often the cause of releasing some object, that's still required by some other part of the program, so not releasing stuff should not be a cause for a crash like yours.
Your issue is looking more like screwed constructor/destructor or operator= then a GL issue.
its just a gues without the actual code to see/test
Most likely you are accessing already deleted pointer somewhere
check all dynamic member variables and pointers inside your class
Had similar problems in the past so check these
trace back pointers in C++
bds 2006 C hidden memory manager conflicts (class new / delete[] vs. AnsiString)
I recommend to take a look at the second link
especially mine own answer, there is nice example of screwed constructor there
Another possible cause
if you are mixing window message code with threads
and accessing visual system calls or objects within threads instead of window code
that can screw up something in the OS and create unexpected crashes ...
at least on windows
I'm having problems with a rather complex piece of code: it throws a PersistentObjectException: Detached entity passed to persist. I'm not going to ask you why, the code is far too complex to post here (multiple joined inheritance classes, OneToMany, ManyToOne, WhateverToWhatever, stuff to avoid 63 tables mysql limit in joins and so on...).
I need only to know if there is a way, during debug, using the variables inspector, to reach the reference to the detached object that caused the exception.
I already know its class, the exception tells it, but I believe I'm not persisting any object of that class (which is abstract by the way...). I'm obviously wrong here, and being able to inspect that object while the program is paused on a breakpoint would be very helpful.
My provider is Hibernate-entitymanager 4.1.9.Final.
Btw, I'm not even calling persist(), I'm calling only merge().
EDIT: I've finally managed to find the detached entity, it took nearly 10 hours of debugging. I guess it could be faster if there were a way to reach the entity through the exception and (more importantly) if the exception message was more precise: the entity class wasn't the one specified, which is abstract, but a subclass of that (obviously I would say, but I have nearly 20 subclasses of that abstract class and guessing the right one was not trivial).
I am developing a gui proram using Qt 4.7.4 (64 bit). I have tried to isolate the problem as follows:
I have a window: class PreferencesWindow : public QMainWindow and in another class I initialize and show it as
QSharedPointer<PreferencesWindow> pPreferencesWindow = QSharedPointer<PreferencesWindow>(new PreferencesWindow());
pPreferencesWindow->show();
it is all good, then I close the window either by pressing ESC or clicking the x button on the window. And then I call
QApplication::quit();
to terminate the whole program. It terminates but gives a segmentation fault just before terminating.
The question here is why it terminates cleanly when I use regular pointer instead of QSharedPointer and how to use QSharedPointer properly in this case?
I suspect the problem is that when you close the window, the data structure pointed to by pPreferencesWindow is deleted without the QSharedPointer's knowledge. When the QSharedPointer itself is later destroyed, it double-deletes the window, and you get the segfault.
Basically, as with all shared pointer implementations, either everybody plays, or nobody does. Since the Qt internals will never know you're using a smart pointer to manage the window, you can't use one. This is a blessing in disguise, however; it means that Qt itself takes possession of the pointer and agrees to manage it for you, so you don't need a smart pointer after all!
I am not an expert with Qt but my first thoughts would be that QMainWindow deletes itself upon destruction and the QSharedPointer object will also delete the object when it's destroyed (i.e. the object is deleted twice). If this is true you don't need to use the QSharedPointer at all.
EDIT: It looks like the QtWidget Qt::WA_DeleteOnClose flag will cause the behaviour I have described.
My current project has a mechanism that tracks/proxies C++ objects to safely expose them to a script environment. Part of its function is to be informed when a C++ object is destroyed so it can safely clean up references to that object in the script environment.
To achieve this, I have defined the following class:
class DeleteEmitter {
public:
virtual ~DeleteEmitter() {
onDelete.emit();
}
sigc::signal<void> onDelete;
};
I then have any class that may need to be exposed to the script environment inherit from this class. When the proxy layer is invoked it connects a callback to the onDelete signal and is thus informed when the object is destroyed.
Light testing shows that this works, but in live tests I'm seeing peculiar memory corruptions (read: crashes in malloc/free) in unrelated parts of the code. Running under valgrind suggests there may be a double-free or continued use of an object after its been freed, so its possible that there is an old bug in a class that was only exposed after DeleteEmitter was added to its inheritance hierarchy.
During the course of my investigation it has occured to me that it might not be safe to emit a sigc++ signal during a destructor. Obviously it would be a bad thing to do if the callback tried to use the object being deleted, but I can confirm that is not what's happening here. Assuming that, does anyone know if this is a safe thing to do? And is there a more common pattern for achieving the same result?
The c++ spec guarantees that the data members in your object will not be destroyed until your destructor returns, so the onDelete object is untouched at that point. If you're confident that the signal won't indirectly result in any reads, writes or method calls on the object(s) being destroyed (multiple objects if the DeleteEmitter is part of another object) or generate C++ exceptions, then it's "safe." Assuming, of course, that you're not in a multi-threaded environment, in which case you also have to ensure other threads aren't interfering.
I'm working on a pretty standard Qt mobile app (written in C++, targeted at Symbian devices), and am finding that sometimes when the app is closed (i.e. via a call to QApplication::quit), the final destructor in the app can take a long time to return (30 seconds plus). By this I mean, all clean up operations in the destructor have completed (quickly, all well within a second) and we've reached the point where execution is leaving the destructor and returning to the code that implicitly called it (i.e. when we delete the object).
Obviously at that point I'd expect execution to return to just after the call to delete the object, virtually instantly, but as I say sometimes this is taking an age!
This long closure time happens both in debug and release builds, with logging enabled or disabled, so I don't think that's a factor here. When we reach the end of the destructor I'm pretty certain no file handles are left open, or any other open resources (network connections etc.)...though even if they where surely this wouldn't present itself as a problem on exiting the destructor (?).
This is on deleting the application's QMainWindow object. Currently the call to do this is in a slot connected to QApplication::aboutToQuit, though I've tried deleting that object in the apps "main" function too.
The length of delay we experience seems proportional to the amount of activity in the app before we exit. This sort of makes me think memory leaks may be a problem here, however we're not aware of any (doesn't mean there aren't any of course), and also I've never seen this behaviour before with leaked memory.
Has anyone any ideas what might be going on here?
Cheers
If your final destructor is for a class than inherits QObject then the QObject destructor will be called immediately following the destructor of your final object. Presumably this object is the root of a possibly large object tree which will trigger a number of actions to occur including calling the destructor of all the child QObjects. Since you state that the problem is componded by the amount of activity, there are likely a very large number of children being added to the object tree that are deleted at this time, perhaps more than you intended. Instead of adding all the objects to one giant tree to be deleted all at once. Identify objects that are being created often that don't need to persist through the entire execution. Instead of creating those objects with a parent, start a new tree that can be deleted earlier (parent =0). Look at QObject::deleteLater() which will wait until there is no user interaction to delete the objects in these independant trees.