Opened 10 years ago
Closed 9 years ago
Last modified 9 years ago
#9545 closed Bug Report - Crash (fixed)
[CRASH] seg fault in network control
Reported by: | Owned by: | Raymond Wagner | |
---|---|---|---|
Priority: | minor | Milestone: | 0.25 |
Component: | MythTV - General | Version: | 0.24-fixes |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | no |
Description
If a network control client closes the connection before the frontend sends the reply, then the ncc is destroyed and when sendReplyToClient tried to see if it's still connected, it segfaults.
fix: set m_socket to NULL in ncc destructor?
From my logs:
2011-02-03 13:45:11.972 ProcessAddRemoveQueues 2011-02-03 13:45:11.972 Construct FD_SET 2011-02-03 13:45:11.972 Waiting on select.. 2011-02-03 13:45:11.972 NetworkControl: emit commandReceived(key right) 2011-02-03 13:45:11.972 NetworkControl: NetworkControl::receiveCommand(key right) 2011-02-03 13:45:11.972 NetworkControl: Client Socket disconnected 2011-02-03 13:45:11.972 SendReceiveStringList(MESSAGE,SYSTEM_EVENT NET_CTRL_DISCONNECTED SENDER fe2) called from UI thread
and a couple of seconds later:
Program terminated with signal 11, Segmentation fault. #0 0x00007f533a6a7944 in QAbstractSocket::state() const () from /usr/lib/libQtNetwork.so.4 (gdb) bt #0 0x00007f533a6a7944 in QAbstractSocket::state() const () from /usr/lib/libQtNetwork.so.4 #1 0x000000000052bd3c in NetworkControl::sendReplyToClient ( this=0x7f532c1ac9e0, ncc=0x2592ec0, reply=...) at networkcontrol.cpp:1120 #2 0x000000000052c602 in NetworkControl::customEvent (this=0x7f532c1ac9e0, e=0x7f532433bed0) at networkcontrol.cpp:1189 #3 0x00007f533a2f1e84 in QObject::event(QEvent*) () from /usr/lib/libQtCore.so.4 #4 0x00007f533ab2732c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4 #5 0x00007f533ab2d80b in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4 #6 0x00007f533a2e209c in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/libQtCore.so.4 #7 0x00007f533a2e5744 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/libQtCore.so.4 #8 0x00007f533a30bb73 in ?? () from /usr/lib/libQtCore.so.4 #9 0x00007f533700a6f2 in g_main_context_dispatch () from /lib/libglib-2.0.so.0 #10 0x00007f533700e568 in ?? () from /lib/libglib-2.0.so.0 # 11 0x00007f533700e71c in g_main_context_iteration () from /lib/libglib-2.0.so.0 #12 0x00007f533a30b6b3 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 ---Type <return> to continue, or q <return> to quit---q Quit (gdb) frame 1 #1 0x000000000052bd3c in NetworkControl::sendReplyToClient ( this=0x7f532c1ac9e0, ncc=0x2592ec0, reply=...) at networkcontrol.cpp:1120 1120 if (client && clientStream && client->state() == QTcpSocket::ConnectedState) (gdb) p client $1 = (struct QTcpSocket *) 0x2592eda (gdb) p clientStream $2 = (struct QTextStream *) 0x24000a000d8f80
Change History (9)
comment:1 Changed 10 years ago by
comment:2 Changed 10 years ago by
Summary: | seg fault in network control → [CRASH] seg fault in network control |
---|
This sounds like a potential candidate for use of QPointer.
comment:3 Changed 10 years ago by
Owner: | set to beirdo |
---|---|
Status: | new → assigned |
comment:4 Changed 10 years ago by
Type: | Bug Report → Bug Report - Crash |
---|
comment:5 Changed 10 years ago by
Status: | assigned → infoneeded |
---|
Can you give me the steps to try to reproduce this here?
comment:6 Changed 10 years ago by
use
tkmythremote frontendhostname
It's in the contrib directory in the 0.22 branch. It connects, sends a command and disconnects without waiting for a response. Just keep hitting buttons until it crashes.
comment:7 Changed 10 years ago by
Status: | infoneeded → assigned |
---|
comment:8 Changed 9 years ago by
Milestone: | unknown → 0.25 |
---|---|
Resolution: | → fixed |
Status: | assigned → closed |
Check for viable connection before sending frontend control response
Add a check in NetworkControl::sendReplyToClient to ensure the client it is trying to send a command response to is one that it knows about. This is to prevent attempting to send a response to a connection that has already be closed by the remote end and deleted.
Fixes #9545
Branch: master Changeset: fc0e279a5a3a73e8e367222a6a9305af20986cbc
comment:9 Changed 9 years ago by
Owner: | changed from beirdo to Raymond Wagner |
---|
Setting m_socket to null didn't fix it, but this does