Details
-
Bug
-
Resolution: Done
-
P2: Important
-
None
-
5.0.0
-
None
Description
With qtdeclarative SHA1 24fb8dc27eddfdd62bd2c3a6e863cbf433762cd6 and qtbase SHA1 d236fe2214340164bec4f34cb27dea4a634ee0de, the attached test passes. The logic in QMetaObject::activate determines that the receiver is in a different thread, and so makes a queued activation.
With more recent SHA1s (e.g., qtdeclarative 8867be2d1d92e981ed736330f036a681ce4b520b and qtbase 6102ab8d646d76a68bb460885394501e90b4fd1f), the test crashes:
********* Start testing of qmlbug ********* Config: Using QTest library 5.0.0, Qt 5.0.0 PASS : qmlbug::initTestCase() [New Thread 0xb32b1b70 (LWP 25389)] [New Thread 0xb2ab0b70 (LWP 25390)] [New Thread 0xb2a9ab70 (LWP 25391)] # # Fatal error in ../3rdparty/v8/src/isolate.h, line 443 # CHECK(isolate != __null) failed # Program received signal SIGTRAP, Trace/breakpoint trap. [Switching to Thread 0xb2a9ab70 (LWP 25391)] v8::internal::OS::DebugBreak () at ../3rdparty/v8/src/platform-linux.cc:389 389 } (gdb) bt #0 v8::internal::OS::DebugBreak () at ../3rdparty/v8/src/platform-linux.cc:389 #1 0xb76baf9c in v8::internal::OS::Abort () at ../3rdparty/v8/src/platform-linux.cc:371 #2 0xb735f5e8 in V8_Fatal (file=0xb76c9db2 "../3rdparty/v8/src/isolate.h", line=443, format=0xb76c9c87 "CHECK(%s) failed") at ../3rdparty/v8/src/checks.cc:58 #3 0xb72fcc1e in v8::internal::Isolate::Current () at ../3rdparty/v8/src/isolate.h:443 #4 0xb735f5db in V8_Fatal (file=0xb76c9db2 "../3rdparty/v8/src/isolate.h", line=443, format=0xb76c9c87 "CHECK(%s) failed") at ../3rdparty/v8/src/checks.cc:55 #5 0xb72fcc1e in v8::internal::Isolate::Current () at ../3rdparty/v8/src/isolate.h:443 #6 0xb735f5db in V8_Fatal (file=0xb76c9db2 "../3rdparty/v8/src/isolate.h", line=443, format=0xb76c9c87 "CHECK(%s) failed") at ../3rdparty/v8/src/checks.cc:55 #7 0xb72fcc1e in v8::internal::Isolate::Current () at ../3rdparty/v8/src/isolate.h:443 #8 0xb7302db7 in v8::HandleScope::HandleScope (this=0xb2a9a01c) at ../3rdparty/v8/src/api.cc:675 #9 0xb7990472 in QQmlBoundSignalExpression::evaluate (this=0x8102b20, secondaryScope=0x81117e0) at qml/qqmlboundsignal.cpp:124 #10 0xb7990f8a in QQmlBoundSignal::subscriptionCallback (e=0x8101c3c, a=0xb2a9a228) at qml/qqmlboundsignal.cpp:305 #11 0xb79d90c5 in QQmlNotifier::emitNotify (endpoint=0x8101c3c, a=0xb2a9a228) at qml/qqmlnotifier.cpp:60 #12 0xb793323b in QQmlData::signalEmitted (object=0x81028d8, index=5, a=0xb2a9a228) at qml/qqmlengine.cpp:449 #13 0xb695f9da in QMetaObject::activate (sender=0x81028d8, m=0x8051c00, local_signal_index=0, argv=0xb2a9a228) at kernel/qobject.cpp:3326 #14 0x0804c236 in MyWorkerObject::done (this=0x81028d8, _t1=...) at main.moc:128 #15 0x0804bc00 in MyWorkerObject::reallyDoIt (this=0x81028d8) at main.cpp:26 #16 0x0804e5ba in QtConcurrent::VoidStoredMemberFunctionPointerCall0<void, MyWorkerObject>::runFunctor (this=0x80f6780) at ../qtbase/include/QtConcurrent/../../src/concurrent/qtconcurrentstoredfunctioncall.h:208 #17 0x0804ce25 in QtConcurrent::RunFunctionTask<void>::run (this=0x80f6780) at ../qtbase/include/QtConcurrent/../../src/concurrent/qtconcurrentrunbase.h:133 #18 0xb677fa21 in QThreadPoolThread::run (this=0x8102a28) at thread/qthreadpool.cpp:98 #19 0xb6784a18 in QThreadPrivate::start (arg=0x8102a28) at thread/qthread_unix.cpp:319 #20 0xb662ce99 in start_thread (arg=0xb2a9ab70) at pthread_create.c:304 #21 0xb646873e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
It seems that now the emission is getting handled by the QML engine, but it doesn't have the same checks of the sender/receiver threads as QObject has. This causes the activation to happen synchronously, which can't work.