Hi,
2014/1/23 Konrad Rosenbaum <kon...@silmor.de> > 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? > > It was intended to live in the main GUI thread. It's here only to advance the _progress counter for testing purposes > 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. > Please read previous posts! This is a dummy lightweight minimalist project that emphasizes on a bug. It does nothing and run() is empty because you will not read my whole 200k lines project and it does not change the crash occurence to strip it out. Yes it terminates after a few µs. > 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. > > No. QThread QObject lives in the main GUI thread and emits signals from there. Never from the new thread. Connecting it to the main GUI thread slots is a very common way to use QThread. By the way, if you emit finished() from run() , that's wrong. It will call direct connections from the wrong thread and signal that the thread is finished while this is not the case. That's bad. > > 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. > > The new threads runs NOTHING (ie run() is empty) so it does not live, does not emit anything, and does not access anything. This can't be the problem, which very likely is in the main thread event loop.
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
