On 09.09.2013 17:37, Thiago Macieira wrote: > On segunda-feira, 9 de setembro de 2013 15:18:26, Benjamin Zeller wrote: >> sendEvent is used, but the receiver is in another thread, shouldn't it >> use postEvent or better shouldn't the threads eventloop do this stuff? >> As a note: the threads eventloop is not running when the crash occurs, >> maybe thats related to it somehow? Is the QObject only moved competely >> to the thread when its eventloop was started? > > sendEvent is supposed to be used there. The object is not supposed to be in > another thread. All socket notifiers being handled by this thread are in this > thread. > > However, your backtrace shows that the same socket object is being used in the > two threads: > #2 0x00007f8fe1422e66 in QAbstractSocketPrivate::readNotification > (this=0xd30ab0) at socket/qabstractsocket_p.h:77 > and > #19 0x00007f8fe141cce7 in QAbstractSocketPrivate::canReadNotification > (this=0xd30ab0) at socket/qabstractsocket.cpp:701 > > Note how the "this" pointer is the same in both threads. > > I can think of only two problems: > > 1) there's a bug in your code and you did not move the object as you thought > you had.
Probably, i will check again, but when i use the debug view in creator i can see that the thread affinity of the SocketEngine is correct. Its in the new thread. Also the worker thread is already handling the Close request while another one is handled in the mainloop. Means the close event is delivered in the correct thread. > 2) there's a lingering bug in the dispatcher that causes it to send events to > objects that have recently been moved away. For example, it's possible that > the event dispatcher got woken up by two socket activities. When handling the > first, you pushed the second socket to another thread. When you resume the > event loop, the dispatcher still tries to handle the second socket, which has > now been moved. It's very likely that there are lots of other socket events, i'm currently doing a stresstest on the server application, lots of requests and connections are opened. Also this does not happen all the time, just on high loads and even then not always. But it always crashes at the same places, in the worker thread and the main thread. This is where the request comes in (mainthread) https://github.com/bzeller/tufao/blob/master/src/threadedhttprequestdispatcher.cpp#L98 where its pushed to the worker: https://github.com/bzeller/tufao/blob/master/src/priv/workerthread.cpp#L48 the threads run function() https://github.com/bzeller/tufao/blob/master/src/priv/workerthread.cpp#L79 If someone wants to test: Webserver Library: https://github.com/bzeller/tufao/ TestApplication: https://github.com/bzeller/tufao-thread-test I did stresstesting with autobench: autobench --single_host --host1 192.168.2.101 --port1 8080 --uri1 /index.html --quiet \ --low_rate 1500 --high_rate 2000 --rate_step 20 --num_call 10 \ --num_conn 5000 --timeout 5 --file results.tsv > > PS: please don't send full backtraces, or at least disable printing of > statics. It's really hard to read it like this. Sorry about that > > > > _______________________________________________ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest > _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
