Possible QtConcurrent/QFuture bug, resulting in SIGSEGV

I'm experiencing crashes when (rapidly!) submitting QtConcurrent::mapped(...) a list of jobs trough signals and slots.
The scenario is as follows:

Rapidly send a QVector of jobs through a slot on a object on another thread.
The slot creates, or recreates a QFuture task with a QtConcurrent::mapped(...) call on the list.
Receive the results (when job is readyAt) in the sender thread, again through a signal-slot.

This scenario crashes randomly, but inevitably. A stacktrace of the crash is as follows:

SIGSEGV

0 QVector<int>::at qvector.h 323 0x00414c27
1 QtConcurrent::ResultIterator<int>::pointer qtconcurrentresultstore.h 117 0x0041491a
2 QtConcurrent::ResultIterator<int>::value qtconcurrentresultstore.h 111 0x004148d9
3 QFutureInterface<int>::resultReference qfutureinterface.h 250 0x00414acb
4 QFuture<int>::resultAt qfuture.h 182 0x00414bc4
5 QFutureWatcher<int>::resultAt qfuturewatcher.h 132 0x004149e7
6 worker::workdoneAt main.cpp 133 0x00411f17
7 worker::qt_metacall main.moc 145 0x0040161a
8 QMetaObject::metacall qmetaobject.cpp 237 0x6a200e14
9 QMetaCallEvent::placeMetaCall qobject.cpp 574 0x6a20b0cf
10 QObject::event qobject.cpp 1252 0x6a20d0f2
11 QApplicationPrivate::notify_helper qapplication.cpp 4242 0x00c32252
12 QApplication::notify qapplication.cpp 3661 0x00c2fdb7
13 QCoreApplication::notifyInternal qcoreapplication.cpp 704 0x6a1fc512
14 QCoreApplication::sendEvent qcoreapplication.h 215 0x6a2604a4
15 QCoreApplicationPrivate::sendPostedEvents qcoreapplication.cpp 1345 0x6a1fd5a3
16 qt_internal_proc qeventdispatcher_win.cpp 507 0x6a21ea87
17 USER32!IsWindowVisible C:\Windows\system32\user32.dll 0 0x759486ef
18 ?? 0 0x00080680
19 ?? 0 0x00000401
20 ?? 0 0x00000000
... <More>

It appears the crush manifests itself when a new job (QFuture) is simultaneously initiated as an access to the result (readyAt())

I'm submitting a simple test case, pretty close to the actual scenarios, though It does just a dummy job.
Again the crash rate is 100% for this sample, though on random timeout.