Openning QMessageBox from asyncroniously called slot leads to crash

[alextai]

I have an QHttp embedded into my wrapper that has :


connect(
_http , SIGNAL( requestFinished(int , bool) ),
this , SLOT( requestProcessingFinished(int , bool) )
);


and has a slot:



void
GetFile::requestProcessingFinished(int id_ , bool error_ )
{
...
emit sig_done(_fileName);
...
}

In main window I do:


connect(
&_getUpdateFile , SIGNAL( sig_done( QString ) ),
this , SLOT( upgradeDownloaded(QString) ) /* ,
Qt::QueuedConnection */
);

where _getUpdateFile is an instance of my wrapper.
Inside upgradeDownloaded I call some function that put's QMessage Box on the
desktop like this:


QMessageBox msgBox(0L);
msgBox.addButton(tr("Run"), QMessageBox::ActionRole);
QPushButton *snoozeButton = msgBox.addButton(tr("Snooze and Run
later"),
QMessageBox::ActionRole);
msgBox.setText(tr("Update has been downloaded. Run update file or
snooze and
run later?"));
msgBox.setIcon(QMessageBox::Icon::Question);
msgBox.exec();

or just with QMessageBox convinience function.
If I do connect without placing explicit Qt:QueuedConnection - I get
segmentation fault. If I put QueuedConnection explicitelly - everything is
working well.
like this:


connect(
&_getUpdateFile , SIGNAL( sig_done( QString ) ),
this , SLOT( upgradeDownloaded(QString) ) ,
Qt::QueuedConnection
);


Is that should be the case that I MUST state what kind of connection I want?
Should not it be automatic and be the care of QT?
I am more the sure that I miss something... but the question is what.
The code compiled with VS2003.
Platform Windows XP SP2.

The backtrace (under windows is):
QtCored4.dll!QEventLoop::exit(int returnCode=0) Line 237 + 0x3 C++
QtGuid4.dll!QDialog::setVisible(bool visible=false) Line 692 C++
QtGuid4.dll!QWidget::hide() Line 434 + 0x14 C++
QtGuid4.dll!QDialog::~QDialog() Line 253 C++
QtGuid4.dll!QMessageBox::~QMessageBox() Line 677 + 0x8 C++
msvcr71d.dll!_CallSettingFrame(unsigned long funclet=1228936, unsigned
long
pRN=259, unsigned long dwInCode=0) + 0x27 Asm
msvcr71d.dll!__FrameUnwindToState(EHRegistrationNo de * pRN=0x0012c088,
void
* pDC=0x00128f00, const _s_FuncInfo * pFuncInfo=0x65812f34, int
targetState=-1) +
0xbf C++
msvcr71d.dll!__InternalCxxFrameHandler(EHException Record *
pExcept=0x00129408, EHRegistrationNode * pRN=0x0012c088, _CONTEXT *
pContext=0x00128f0c, void *
pDC=0x00128f00, const _s_FuncInfo * pFuncInfo=0x65812f34, int CatchDepth=0,
EHRegistrationNode * pMarkerRN=0x00000000, unsigned char recursive=0) + 0x4d
C++
> msvcr71d.dll!__CxxFrameHandler(EHExceptionRecord * pExcept=0x00129408,
EHRegistrationNode * pRN=0x0012c088, void * pContext=0x00128f0c, void *
pDC=0x00128f00) +
0x2c C++
ntdll.dll!7c9037bf()
ntdll.dll!7c90378b()
ntdll.dll!7c937b48()
kernel32.dll!7c81eb33()

[ChristianEhrlicher]

I assume your wrapper class is a separate Thread. If so then the answer is - yes you always need the queued connection as only the main-thread can do graphical output (this was discussed here very often already).

[alextai]

No... My wrapper is not running additional thread.
QT's documentation is stating that if I do not specify connection type it is set to automatic... meaning that if receiver owner is a different thread then the signal will be delivered through message queue.
Also there are examples for QHttp that do not have any specific connection type stated.