Проблема с сервером (deleteLater() для сокета вызывает SegFault)

[Patrin Andrey]

Ну давайте посмотрим. Само по себе от удаления объекта ничего упасть не может. Должно быть обращение к нему (ну или к подобъектам, если судить по стеку).
Значит что? Что мы хотим в нашем processEvents мы не хотим допустить обращения к сокету.
Какой флаг нам нужен? Правильно, QEventLoop::ExcludeSocketNotifiers.

Проблема в том, что может быть сложно контролировать все слоты подключённые к signalSendTextToLog (или другим сигналам, которые мы будем эмитить). В итоге эти грабли будут всплывать опять и опять.

[Ground]

В итоговом решение объединил два совета. Сделал 2 сигнала и соединил их через Qt::QueuedConnection, а в слоте работы с UI добавил processEvent с параметром QEventLoop::ExcludeSocketNotifiers.
Если применять первое решение с 2 сигналами - программа падает и по стеку вызов видно, что ошибка где-то в moc-файле. Я там уже разбираться не стал. Само падение происходит при обращении к параметру сигнала text.
Если применять второе решение с QEventLoop::ExcludeSocketNotifiers - программа работает стабильно, UI не виснет, но сервер частенько бросает предупреждения вида:

Код

C++ (Qt)
QSocketNotifier: Invalid socket specified
QSocketNotifier: Internal error

Что, в принципе, логично, учитывая, что мы удаляем объект, а потом только обрабатываем уведомления от сокета. Если же объединить два варианта, сервер ведет себя стабильно, при полной загрузке работает уже час без сбоев.
В случае же, если при увеличении нагрузке вылезет подобный баг - либо полезу разбираться дальше глубже, в причине проблемы, либо просто уменьшу вывод информации в лог сервера и отключу функцию processEvents(). Одним словом, теперь я знаю где искать

Вопрос можно считать закрытым. Спасибо всем, кто помогал. И отдельное, большое человеческое спасибо, Patrin Andrey, сам бы вряд-ли докопался до истинной причины бага

[mutineer]

Я не думаю что ты докопался до истинной причины бага. Тебе не приходила в голову мысль, что раз приходится писать такие странные костыли для несложного, в общем-то, действия, то у тебя что-то сильно не так с подходом?

З.Ы. По теме не мог помочь, потому что код, на мой взгляд, странный весь

[Ground]

З.Ы. По теме не мог помочь, потому что код, на мой взгляд, странный весь

Ну так вы подскажите, в чем странность?

Плюс я бы не сказал, что это костыли. Точнее не так. Если уж говорить про костыли, то это - processEvents(). Не было бы этой функции, код отрабатывал бы нормально. А чтобы ее не было - нужно было изначально делать сервер многопоточным.

[mutineer]

З.Ы. По теме не мог помочь, потому что код, на мой взгляд, странный весь

Ну так вы подскажите, в чем странность?

На мой взгляд странность во всем. Например, disconnect не нужен. Не удалять пустой указатель из списка ммм... необычно. Какой смысл в QPointer, если ты вручную управляешь жизнью сокета? Зачем делать close(), если сокет и так уже отключился?

[Ground]

З.Ы. По теме не мог помочь, потому что код, на мой взгляд, странный весь

Ну так вы подскажите, в чем странность?

На мой взгляд странность во всем. Например, disconnect не нужен. Не удалять пустой указатель из списка ммм... необычно. Какой смысл в QPointer, если ты вручную управляешь жизнью сокета? Зачем делать close(), если сокет и так уже отключился?

Ну я же тоже это все не просто написал.
disconnect() в данном случае нужен для того, чтобы во время удаления сокета не получить другой сигнал, на прием/чтение данных. Ведь согласно документации, автоотключение происходит лишь при уничтожении объекта. А сколько пройдет до этого момента? Я уж лучше отключу сигнал вручную. Были у меня случаи с таким багом.
close() нужен для тех случаев, когда disconnectClient() вызывается не из слота rejectClient, а, допустим, во время остановки сервера. В close() стоит проверка, не находится ли сокет в состоянии закрытия, так что мы ничего не теряем при вызове этой функции, зато уменьшаем объем нашего кода.
Насчет не удаления пустого указателя - я голову уже пеплом выше посыпал, у меня фиксированный массив клиентов. Т.е. в конфиге написали - 512, лимит - 512.
И где я управляю жизнью сокета? То, что я его зануляю? Это привычка, и я не назову ее плохой. Пусть уж лучше у меня будет нулевой указатель и QPointer со значением NULL, чем указатель непонять куда и опять же QPointer == NULL. В обоих случаях же, сокет уведомит QPointer о своем разрушении. В общем, мне так спокойнее.

Сейчас вы указали лишь некоторые кода недостатки (для вас), которые вряд ли являются критическими для восприятия проблемы в целом.

[mutineer]

Для Patrin Andrey они не являются критическими, а вот для меня являются. Я не хочу критиковать твой код, а хочу обратить внимание на то, что создание таких костылей, которыми является итоговое решение, может быть результатом неправильного подхода к написанию сервера

[Ground]

Для Patrin Andrey они не являются критическими, а вот для меня являются. Я не хочу критиковать твой код, а хочу обратить внимание на то, что создание таких костылей, которыми является итоговое решение, может быть результатом неправильного подхода к написанию сервера

Ну так и я же пытаюсь понять, что мне исправить, чтобы получить правильный сервер. Пока что я только вынес для себя одно замечание - сменить фиксированный массив с сокетами на список.

Ваш пример с QPointer - это дело личного вкуса, к серверу же не относится.
С ручным отключением сигналов. Ну я вот так прикинул, можно было в самом слоте получения данных сделать проверку, находится ли сокет в состоянии Connected. Это вы считаете правильным решением приведенной мной проблемы?

[mutineer]

Блин... Придется удалить одно из своих сообщений, видимо...

Еще раз. То, что я перечислил - это моменты, мешающие лично мне ответить на вопрос "почему SegFault и как его избежать?". Что может быть не так с твоим подходом я не знаю как минимум по двум причинам:
1) не видно всего кода, а есть только кусок с удалением
2) не факт что я сам знаю правильных подход, но костыльность решения намекает что он может отличаться от твоего.

Так понятно?

[Ground]

Блин... Придется удалить одно из своих сообщений, видимо...

Еще раз. То, что я перечислил - это моменты, мешающие лично мне ответить на вопрос "почему SegFault и как его избежать?". Что может быть не так с твоим подходом я не знаю как минимум по двум причинам:
1) не видно всего кода, а есть только кусок с удалением
2) не факт что я сам знаю правильных подход, но костыльность решения намекает что он может отличаться от твоего.
Так понятно?

Более чем.

[Пантер]

Я согласен с mutineer - код оставляет желать лучшего. Допустим, у меня в одной проге вот так сделано:

Код

C++ (Qt)
void SocketListener::addConnection_p (QTcpSocket *socket)
{
	connect (socket, SIGNAL (readyRead()), SLOT (readyRead()));
	connect (socket, SIGNAL (disconnected()), SLOT (disconnected()));
 
	sockets_.push_back ( {socket, false});
	qDebug () << "New connection" << socket->peerAddress ();
}
 
void SocketListener::readyRead()
{
	QTcpSocket *socket = qobject_cast <QTcpSocket *> (sender ());
	Q_CHECK_PTR (socket);
 
	do {
		const QString reply = Utils::readLineFromSocket (socket);
 
		if (!replyAnalizer_.setReply (reply, socket)) {
			qWarning () << "Socket reply is incorrect" << reply;
			socket->disconnectFromHost ();
		}
	} while (socket->canReadLine ());
}
 
void SocketListener::disconnected()
{
	QTcpSocket *socket = qobject_cast <QTcpSocket *> (sender ());
	Q_CHECK_PTR (socket);
 
	qDebug () << "Closed connection" << socket->peerAddress ();
 
	socket->deleteLater ();
	sockets_.erase (findSocket (socket));
}
 
SocketListener::Sockets::iterator SocketListener::findSocket (QTcpSocket *socket)
{
	return std::find_if (sockets_.begin(),
						 sockets_.end(),
	[socket] (const Socket & s) -> bool {
		return s.first == socket;
	}
						);
}
 

[Patrin Andrey]

Я не думаю что ты докопался до истинной причины бага.

Истинная причина бага - то что во время обработки readyRead сокет удаляется. А чтобы этого не происходило нужно исключить исполнение кода, который может выполнить такие действия(совершенно об этом не подозревая)

PS. по поводу кода - мне он тоже не нравится.

[mutineer]

Я не думаю что ты докопался до истинной причины бага.

Истинная причина бага - то что во время обработки readyRead сокет удаляется. А чтобы этого не происходило нужно исключить исполнение кода, который может выполнить такие действия(совершенно об этом не подозревая)

Какая может быть обработка readyRead, если для удаления сокет должен перейти в disconnected состояние и никаких данных получать уже не может?

[Patrin Andrey]

Упс, только что заметил что в slotReceiveData вызывается slotDisconnectClient а не disconnectClient(отличные названия, блин). Если из  slotDisconnectClient не вызывается disconnectClient то ниженаписанное можно не читать, а если вызывается, то:
в slotReceiveData()
if (!result)
   this->slotDisconnectClient(clientNumber);
а там deleteLatter для сокета(фактически внутри ReadyRead). теперь достаточно чтобы лишь дать выполниться этому делету, и всё - мы внутри readyRead удалённого сокета.

[mutineer]

А зачем вообще вызывать удаление сокета из чтения данных?