QTcpServer newConnection signal not emitted when QMainWindow is instantiated

[J.Hilk]

@izkb stupid question, but one easily forgotten, is your server-program blocked by your firewall?

[izkb]

@jsulm The connected() signal is emitted by the client upon connection. Here is a broken-down example of the client code which is built and run in a different project:

//.h
class tcp_client_class : public QObject
{
    Q_OBJECT
public:
   tcp_client_class();
private:
    QTcpSocket tcpClientSocket;
private slots:
    void slotRxReady(void);
    void slotHandleTcpError(const QAbstractSocket::SocketError socketError);
    void slotTcpConnectSuccess(void);
}

//.cpp
tcp_client_class::tcp_client_class(): QObject()
{
   tcpClientSocket.setSocketOption(QAbstractSocket::LowDelayOption,1);
   connect(&tcpClientSocket, SIGNAL(connected()), this, SLOT(slotTcpConnectSuccess()));
   connect(&tcpClientSocket, SIGNAL(readyRead()), this, SLOT(slotRxReady()));
   connect(&tcpClientSocket, SIGNAL(error(QAbstractSocket::SocketError)), this, SLOT(slotHandleTcpError(const QAbstractSocket::SocketError)));

tcpClientSocket.connectToHost("127.0.0.1", 2021);
}

void tcp_client_class::slotTcpConnectSuccess()
{
   emit sigSocketConnected();
   qDebug() << "TCP Client Interface: TCP Socket connection success";
}

[jsulm]

@izkb Last idea I have: do you see the debug message "Server listening on port"? Maybe something else is listening on this port? Is another instance of your server app still running?

[izkb]

@J-Hilk Turning off the firewall and antivirus does not solve the problem and the client still connects

@jsulm No nothing else is listening on this port. I checked in the Windows Resource monitor and closing and re-opening Qt also does not help

[J.Hilk]

@izkb mmh, can you connect to ther fortune-server example with your client?

[jsulm]

@izkb And do you see "Server listening on port"?

[izkb]

@J.Hilk Yes I can connect to the fortuneserver example

@jsulm Yes that is displayed

[SGaist]

Hi and welcome to devnet,

From what I can see, you try to bind to localhost while listening on any of the network interfaces. You should replace QHostAddress::Any by QHostAddress::LocalHost.

In any case, a call to QTcpServer::serverAddress should give you a clue about which address to use to connect to sour server object.

[izkb]

Hi @SGaist
Replacing QHostAddress::Any with QHostAddress::LocalHost and printing server->serverAddress displays 127.0.0.1 which is the address to which the client is connecting and as mentioned the client connects successfully, the problem is on the server side which does not register a new connection.

The problem must be on the eventloop and possibly results from the server being contained in a QMainWindow object, since the FortuneServer example derives a QDialog class and works on my system. Are there any known issues of this sort with QMainWindow?

[jsulm]

@izkb I'm quite sure the issue isn't QMainWindow as it has an event loop as well. It doesn't matter whether it is QMainWindow or QDialog. As long as you don't block the event loop it should work.
What else are you doing in your server? Do you by any chance blocking the event loop?

[izkb]

@jsulm
The server code provided is the only code I am using at the moment and as far as I know nothing there should block the eventloop...
Could it not be that QMainWindow creates separate threads which might break the inner workings of the QTcpServer class?

[jsulm]

@izkb No, QMainWindow does not create any threads- why should it? Even if it would why should those threads break QTcpServer?

[J.Hilk]

@izkb If you think, creating the server in the constructor of your mainclass is the issue, why don't you move that away than?

#include <QTimer>

server = Q_NULLPTR;
   connect(server, QTcpServer::newConnection, this, &NetmanSim2_class::slotServerConnected);

QTimer::singleShot(0,this,[=]{
    server = new QTcpServer(this);
    if(!server->listen()){
        qDebug() << "Unable to open Server";
    }else qDebug() << "Server Read for Connection";
});

The QTimer of 0ms means will be executed next eventloop cycle.

[SGaist]

One thing that is missing in your code: acceptError handling. That might provide additional information about what is happening.

[izkb]

I found the solution:

Due to a stackoverflow upon initial project setup, I added the following to the .pro file:
QMAKE_LFLAGS += /STACK:256000000

Removing one 0 from the size resulted in the server working correctly.

Why would a large stack size break the eventloop though? I have used the same stack size for other projects without problems.

[SGaist]

Out of curiosity, what triggers the need to modify to such a high value ?

[izkb]

@SGaist
There was no need, the value was simply copied from a larger project where it was required. Thanks all for the attempts at helping.