Murphy, Sean
2014-10-29 18:35:49 UTC
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 0x6704e6d2
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 0x6b965de7
8 QEventLoop::processEvents qeventloop.cpp 136 0x6b919650
9 QEventLoop::exec qeventloop.cpp 212 0x6b9198eb
10 QThread::exec qthread.cpp 509 0x6b794f85
11 QThread::run qthread.cpp 576 0x6b7950ed
12 QThreadPrivate::start qthread_win.cpp 347 0x6b797ac2
13 msvcrt!_itow_s C:\windows\syswow64\msvcrt.dll 0x775d1287
14 msvcrt!_endthreadex C:\windows\syswow64\msvcrt.dll 0x775d1328
15 KERNEL32!BaseCleanupAppcompatCacheSupport C:\windows\syswow64\kernel32.dll 0x7594338a
16 ?? 0x16d0ffd4
17 ntdll!RtlpNtSetValueKey C:\windows\system32\ntdll.dll 0x77c19f72
18 ?? 0x166b7660
19 ntdll!RtlpNtSetValueKey C:\windows\system32\ntdll.dll 0x77c19f45
20 msvcrt!_endthreadex C:\windows\syswow64\msvcrt.dll 0x775d12e5
21 ??
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 0x6704e6d2
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 0x6b965de7
8 QEventLoop::processEvents qeventloop.cpp 136 0x6b919650
9 QEventLoop::exec qeventloop.cpp 212 0x6b9198eb
10 QThread::exec qthread.cpp 509 0x6b794f85
11 QThread::run qthread.cpp 576 0x6b7950ed
12 QThreadPrivate::start qthread_win.cpp 347 0x6b797ac2
13 msvcrt!_itow_s C:\windows\syswow64\msvcrt.dll 0x775d1287
14 msvcrt!_endthreadex C:\windows\syswow64\msvcrt.dll 0x775d1328
15 KERNEL32!BaseCleanupAppcompatCacheSupport C:\windows\syswow64\kernel32.dll 0x7594338a
16 ?? 0x16d0ffd4
17 ntdll!RtlpNtSetValueKey C:\windows\system32\ntdll.dll 0x77c19f72
18 ?? 0x166b7660
19 ntdll!RtlpNtSetValueKey C:\windows\system32\ntdll.dll 0x77c19f45
20 msvcrt!_endthreadex C:\windows\syswow64\msvcrt.dll 0x775d12e5
21 ??