Hi, On Thursday, Thursday 23 January 2014 at 10:15, Etienne Sandré-Chardonnal wrote: > Here is the only non trivial code that could contain the bug if it's not a > Qt bug. This is a QThread subclass worker doing the file saving (here it > does nothing but this crashes anyway on the QProgressDialog destruction)
I don't think this code does what you expect it to do. startWriting() is called in the main thread, this is probably intended all signal-slot-connections made inside this function are direct connections and probably executed in the main thread - did you intend this or can I assume the timer was supposed to live in the new thread? If some of those connections are handled outside the main thread, it could explain the crash: GUI events MUST NOT be executed outside the GUI thread. It also is usually a bad idea to execute methods of the same object in multiple threads (unless they are specifically protected by locks). Why is run() empty? As far as I understand QThread this means the thread lives for only a few microseconds and then self-destructs. I have not completely understood what that does to the timer and progress dialog yet. I think I have a possible reason why the progress dialog may crash: the finished() signal is emitted from within the new thread, since the connection is direct (automatic means direct in this specific case) the close() method is called inside the wrong thread. backgroundfileworker.cpp, line 35: try adding Qt::QueuedConnection actually: I would add this to almost all connects in this scenario! Somewhere else in this mailthread: it does not matter whether the program crashes on Linux, valgrind (helgrind, drd) detects race conditions no matter whether they are triggering a problem right now by detecting memory access that is not protected by locks/semaphores. Konrad
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest