[Interest] Annoying Bug - Qt 4.8.1 bug?

[Etienne Sandré-Chardonnal]

Hi,


2014/1/23 Konrad Rosenbaum <konrad at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20140123/3837bd10/attachment.html>