[Interest] Crash in QSerialPort when closing?
Murphy, Sean
smurphy at walbro.com
Wed Oct 29 20:14:18 CET 2014
> Your version of QtSerialPort is too very old (according to call-stack).
> Please update to latest (e.g. to 5.3.2/5.3.3).
I'll try to upgrade then. If that's all it is, that'd be great!
Sean
>> I’m getting a weird issue where I can repeatedly cause a crash to happen in QSerialPort if I attempt to close the
>> serial port when I’m in a slot connected to the readyRead() signal, and I’m just wondering if I’m doing something
>> weird.
>>
>> I’ve got a class that inherits from QSerialPort. I instantiate this object in the UI thread but immediately move it to a
>> separate thread. This object has a slot, disconnectFromDevice(), that sends a reset command to the serial device.
>>
>> So the way I intended the software to work is the user clicks the disconnect button in the UI thread, which sends a
>> signal to the serial port object. That object sends the reset command to the serial device and the serial device
>> responds with an acknowledge response. The acknowledge response triggers the QSerialPort::readyRead() signal,
>> which triggers my readyRead() slot. I parse the acknowledge, then emit a signal back to the UI thread letting the
>> UI know that the disconnect was successful, and then call QSerialPort::close() in the serial port object (still inside of
>> my readyRead() slot).
>>
>> When I execute setup in a debug build, at this point the application crashes with a SIGSEV. For some reason it kicks
>> me into the disassembler instead of breaking in my code. If I comment out the close() call, the segfault doesn’t
>> happen.
>>
>> Below is what’s shown in the call stack, but since none of my code is shown in the call stack, I don’t know if I’m
>> crashing on the close() call itself, or if I crash sometime later because I’m doing something when the port isn’t
>> open. If I set a breakpoint anywhere in my readyRead() slot the crash DOESN’T occur. I only know that removing
>> the close() call removes the crash.
>>
>> Any ideas? Specifically, why am I not seeing any of my calls in the call stack?
>> Sean
>>
>> 0 ReadOverlappedCompletionNotifier::processCompletionRoutine qserialport_win.cpp 188 0x6704e8ed
>> 1 AbstractOverlappedEventNotifier::event qserialport_win.cpp 119
>> 2 QApplicationPrivate::notify_helper qapplication.cpp 3467 0xa9ede0f
>> 3 QApplication::notify qapplication.cpp 2888 0xa9eb72b
>> 4 QCoreApplication::notifyInternal qcoreapplication.cpp 878 0x6b91b572
>> 5 QCoreApplication::sendEvent qcoreapplication.h 232 0x6b9bee2b
>> 6 QEventDispatcherWin32Private::activateEventNotifier qeventdispatcher_win.cpp 335 0x6b9646e8
>> 7 QEventDispatcherWin32::processEvents qeventdispatcher_win.cpp 759
>> 8 QEventLoop::processEvents qeventloop.cpp 136
>> 9 QEventLoop::exec qeventloop.cpp 212
>> 10 QThread::exec qthread.cpp 509
>> 11 QThread::run qthread.cpp 576
>> 12 QThreadPrivate::start qthread_win.cpp 347
>> 13 msvcrt!_itow_s C:\windows\syswow64\msvcrt.dll
>> 14 msvcrt!_endthreadex C:\windows\syswow64\msvcrt.dll
>> 15 KERNEL32!BaseCleanupAppcompatCacheSupport C:\windows\syswow64\kernel32.dll 0x7594338a
>> 16 ??
>> 17 ntdll!RtlpNtSetValueKey C:\windows\system32\ntdll.dll
>> 18 ??
>> 19 ntdll!RtlpNtSetValueKey C:\windows\system32\ntdll.dll
>> 20 msvcrt!_endthreadex C:\windows\syswow64\msvcrt.dll
>> 21 ??
More information about the Interest
mailing list