Qt Forum

    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Unsolved

    Update: Forum Guidelines & Code of Conduct


    Qt World Summit: Early-Bird Tickets

    Unsolved App crash calling QTcpSocket::waitForConnected

    General and Desktop
    4
    15
    3385
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • K
      Kiyov09 last edited by

      Hi, I have the following error:
      the next function is called multiple times from diferent threads and after some time, say 20 minutes, crash in socket->waitForConnected(1000). Anybody? Thanks.

      bool Utils::testConnectionToServer(QString host, int port)
      {
          QTcpSocket * socket = new QTcpSocket();
          socket->connectToHost(host, port, QIODevice::ReadOnly);
          if (socket->waitForConnected(1000)) {
              socket->abort();
              socket->close();
              delete socket;
              socket = 0;
              return true;
          } else {
              qDebug() << "### " << socket->errorString() << " ###";
              delete socket;
              socket = 0;
              return false;
          }
      }
      
      1 Reply Last reply Reply Quote 0
      • mrjj
        mrjj Lifetime Qt Champion last edited by

        Hi and welcome
        Have you checked that new can allocate always ?
        You might fragment memory if calls happens really fast.

        Also , any chance that the threads call it at the SAME time ?
        so following situation could arise ? (when times perfectly)
        QTcpSocket * socket = new QTcpSocket(); << Thread 1 here
        socket->connectToHost(host, port, QIODevice::ReadOnly) ; << Thread 2 here

        1 Reply Last reply Reply Quote 0
        • K
          Kiyov09 last edited by

          Previously he had a version of the function that used QMutexLocker to avoid just that but also crash in waitForConnected. Specifically, the error displayed is as follows:

          *** buffer overflow detected ***: /home/kiyov/RepoSVN/tss-streamingserver/trunk/StreamingServer/StreamingServer/Server terminated
          ======= Backtrace: =========
          /lib/x86_64-linux-gnu/libc.so.6(+0x731ff)[0x7ffff493b1ff]
          /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7ffff49be4c7]
          /lib/x86_64-linux-gnu/libc.so.6(+0xf46e0)[0x7ffff49bc6e0]
          /lib/x86_64-linux-gnu/libc.so.6(+0xf6437)[0x7ffff49be437]
          /usr/lib/x86_64-linux-gnu/libQtNetwork.so.4(+0xd4e25)[0x7ffff5968e25]
          /usr/lib/x86_64-linux-gnu/libQtNetwork.so.4(+0xd2a8d)[0x7ffff5966a8d]
          /usr/lib/x86_64-linux-gnu/libQtNetwork.so.4(_ZN15QAbstractSocket16waitForConnectedEi+0x14a)[0x7ffff595f27a]
          /home/kiyov/RepoSVN/tss-streamingserver/trunk/StreamingServer/StreamingServer/Server[0x439eda]
          /home/kiyov/RepoSVN/tss-streamingserver/trunk/StreamingServer/StreamingServer/Server[0x4360c2]
          /home/kiyov/RepoSVN/tss-streamingserver/trunk/StreamingServer/StreamingServer/Server[0x439a9e]
          /home/kiyov/RepoSVN/tss-streamingserver/trunk/StreamingServer/StreamingServer/Server[0x4151ab]
          /home/kiyov/RepoSVN/tss-streamingserver/trunk/StreamingServer/StreamingServer/Server[0x458e9b]
          /usr/lib/x86_64-linux-gnu/libQtCore.so.4(_ZN7QObject5eventEP6QEvent+0x1e1)[0x7ffff5544e11]
          /usr/lib/x86_64-linux-gnu/libQtCore.so.4(_ZN16QCoreApplication14notifyInternalEP7QObjectP6QEvent+0x8d)[0x7ffff552b71d]
          /usr/lib/x86_64-linux-gnu/libQtCore.so.4(_ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData+0x231)[0x7ffff552efc1]
          /usr/lib/x86_64-linux-gnu/libQtCore.so.4(+0x1b5bd3)[0x7ffff555abd3]
          /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x24d)[0x7ffff641dc5d]
          /lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x49f48)[0x7ffff641df48]
          /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_iteration+0x2c)[0x7ffff641dffc]
          /usr/lib/x86_64-linux-gnu/libQtCore.so.4(_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE+0x5d)[0x7ffff555ad1d]
          /usr/lib/x86_64-linux-gnu/libQtCore.so.4(_ZN10QEventLoop13processEventsE6QFlagsINS_17ProcessEventsFlagEE+0x41)[0x7ffff552a271]
          /usr/lib/x86_64-linux-gnu/libQtCore.so.4(_ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE+0x1a5)[0x7ffff552a5d5]
          /usr/lib/x86_64-linux-gnu/libQtCore.so.4(_ZN16QCoreApplication4execEv+0x99)[0x7ffff5530059]
          /home/kiyov/RepoSVN/tss-streamingserver/trunk/StreamingServer/StreamingServer/Server[0x40cf12]
          /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7ffff48e9b45]
          /home/kiyov/RepoSVN/tss-streamingserver/trunk/StreamingServer/StreamingServer/Server[0x40ce09]
          
          1 Reply Last reply Reply Quote 0
          • mrjj
            mrjj Lifetime Qt Champion last edited by

            Hi
            it looks like buffer overrun happens inside Qt.
            Have you searched the bug database for issues sounding like this`?

            K 1 Reply Last reply Reply Quote 0
            • K
              Kiyov09 @mrjj last edited by

              @mrjj no, where I can search that bug?

              mrjj 1 Reply Last reply Reply Quote 0
              • mrjj
                mrjj Lifetime Qt Champion @Kiyov09 last edited by mrjj

                @Kiyov09
                https://bugreports.qt.io/secure/Dashboard.jspa

                https://bugreports.qt.io/browse/QTBUG-7753?jql=text ~ "waitForConnected"

                K 1 Reply Last reply Reply Quote 0
                • K
                  Kiyov09 @mrjj last edited by

                  @mrjj Thanks

                  mrjj 1 Reply Last reply Reply Quote 0
                  • mrjj
                    mrjj Lifetime Qt Champion @Kiyov09 last edited by

                    @Kiyov09
                    Hope you find something.

                    Is it always after the same amount of calls?

                    K 1 Reply Last reply Reply Quote 0
                    • K
                      Kiyov09 @mrjj last edited by

                      @mrjj I do not know, I have done this test.

                      1 Reply Last reply Reply Quote 0
                      • SGaist
                        SGaist Lifetime Qt Champion last edited by

                        Hi and welcome to devnet,

                        I'd change the delete statement by socket->deleteLater() to ensure that you are not deleting the sockets while there's still an event going on the socket.

                        Interested in AI ? www.idiap.ch
                        Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

                        1 Reply Last reply Reply Quote 0
                        • K
                          Kiyov09 last edited by

                          @mrjj No, but it made approximately 1348 calls.

                          @SGaist Even changing the delete statement by socket->deleteLeter() the problem persist.

                          Apparently all starts in the call to QNativeSocketEnginePrivate::nativeSelect.

                          This is the stack trace
                          0 __GI_raise raise.c 56 0x7ffff48fd107
                          1 __GI_abort abort.c 89 0x7ffff48fe4e8
                          2 __libc_message libc_fatal.c 175 0x7ffff493b204
                          3 __GI___fortify_fail fortify_fail.c 31 0x7ffff49be4c7
                          4 __GI___chk_fail chk_fail.c 28 0x7ffff49bc6e0
                          5 __fdelt_chk fdelt_chk.c 25 0x7ffff49be437
                          6 QNativeSocketEnginePrivate::nativeSelect qnativesocketengine_unix.cpp 1073 0x7ffff5968e25
                          7 QNativeSocketEngine::waitForWrite qnativesocketengine.cpp 947 0x7ffff5966a8d
                          8 QAbstractSocket::waitForConnected qabstractsocket.cpp 1814 0x7ffff595f27a
                          9 Utils::testConnectionToServer Utils.cpp 106 0x43a099
                          10 MyAmqpClient::publishMessage myamqpclient.cpp 206 0x4361d2
                          11 Utils::sendMessageToAmqp Utils.cpp 73 0x439bae
                          12 StreamingServer::checkSystemResources streamingserver.cpp 1083 0x4152bb
                          13 StreamingServer::qt_static_metacall moc_streamingserver.cpp 107 0x459099
                          14 QObject::event qobject.cpp 1222 0x7ffff5544e11
                          15 QCoreApplication::notifyInternal qcoreapplication.cpp 955 0x7ffff552b71d
                          16 sendEvent qcoreapplication.h 231 0x7ffff552efc1
                          17 QCoreApplicationPrivate::sendPostedEvents qcoreapplication.cpp 1579 0x7ffff552efc1
                          18 QCoreApplication::sendPostedEvents qcoreapplication.cpp 1472 0x7ffff552f453
                          19 sendPostedEvents qcoreapplication.h 236 0x7ffff555abd3
                          20 postEventSourceDispatch qeventdispatcher_glib.cpp 280 0x7ffff555abd3
                          ... <More>

                          1 Reply Last reply Reply Quote 0
                          • J
                            Jodavi last edited by Jodavi

                            Hello everyone,

                            sorry for reviving that old thread, but it looks nearly the same as my problem.

                            I am using QT 5.6.2 on a headless gentoo. My (QCore) application is using sockets with multiple threads.

                            The threads are in a threadpool. Every thread sends its result to the same target after finishing its work (~0.5 to 10 seconds). Each "sends its result" involves a code like this:

                            int WorkerThread::sendMessageOverTCPSocket(const QString & result, const QString &ip, const quint16 &port)
                            {
                              try
                              {
                            	QTcpSocket socket;
                            	socket.connectToHost(ip,port);
                            	if(socket.waitForConnected(10203))
                            	{
                            		socket.write(result.toStdString().c_str(),result.length());
                            		if(!socket.waitForBytesWritten(5134))
                            		{
                            			ss << m_id <<":timeout while writing data to socket";
                            			LOG(ss.str().c_str()); ss.str("");
                            			return Constants::TCPSOCKETERROR::TIMEOUT_WAIT_WRITTEN;
                            		}
                            	}
                            	else
                            	{
                            		ss << m_id <<":could not connect to socket";
                            		LOG(ss.str().c_str()); ss.str("");
                            		return Constants::TCPSOCKETERROR::TIMEOUT_CONNECTED;
                            	}
                            	socket.close();
                              }
                              catch (std::exception &e)
                              {
                            	qFatal("Error(%s) sending results ",e.what());
                              }
                              catch (...)
                              {
                            	qFatal("Unknown error occured while trying to send results");
                              }
                            
                              return 0;
                            }
                            

                            After about 1100 -1300 threads, the application always terminates. This may take up to a couple of days until it happens "naturally". The one I am currently investigating terminates with SIGABRT.

                            No immediate output or log can be found.

                            This is a bt from a sample coredump

                            #0  0x00007faa868442b8 in raise () from /lib64/libc.so.6
                            #1  0x00007faa868456da in abort () from /lib64/libc.so.6
                            #2  0x00007faa868803f1 in __libc_message () from /lib64/libc.so.6
                            #3  0x00007faa86908b27 in __fortify_fail () from /lib64/libc.so.6
                            #4  0x00007faa86906bb0 in __chk_fail () from /lib64/libc.so.6
                            #5  0x00007faa86908a9a in __fdelt_warn () from /lib64/libc.so.6
                            #6  0x00007faa8a0737a4 in ?? () from /usr/lib64/libQt5Network.so.5
                            #7  0x00007faa8a070ce2 in ?? () from /usr/lib64/libQt5Network.so.5
                            #8  0x00007faa8a06a5dc in QAbstractSocket::waitForConnected(int) () from /usr/lib64/libQt5Network.so.5
                            

                            The line number points to the if(socket.waitForConnected(10203))

                            Can someone hint me to the right direction? There seems to be no solution posted to the problem of OP

                            Edit: Updated code

                            1 Reply Last reply Reply Quote 0
                            • SGaist
                              SGaist Lifetime Qt Champion last edited by SGaist

                              Hi and welcome to devnet,

                              Are you sure you are cleaning up properly your resources when you're done ?

                              Interested in AI ? www.idiap.ch
                              Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

                              J 1 Reply Last reply Reply Quote 0
                              • J
                                Jodavi @SGaist last edited by

                                @SGaist
                                Thanks for the welcome!

                                The resources in use are all local and should get cleaned up, once they are out of scope.
                                See the update in my post above.

                                I am not sure whether this really is "properly cleaning up". Actually, I assumed the DTOR of the QTCPSocket is enough?
                                From the docs:

                                [virtual] QTcpSocket::~QTcpSocket()
                                Destroys the socket, closing the connection if necessary.
                                See also close().
                                

                                My current vague suspicion:
                                Is the line socket.close(); positioned correctly?

                                1 Reply Last reply Reply Quote 0
                                • SGaist
                                  SGaist Lifetime Qt Champion last edited by

                                  Looks like it.

                                  How are you handling your thread pool ?

                                  Interested in AI ? www.idiap.ch
                                  Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

                                  1 Reply Last reply Reply Quote 0
                                  • First post
                                    Last post