2016-03-17 21 views
5

Mamy aplikację OS X C++, używając Qt 5.5, która zapewnia prosty interfejs serwera HTTP. To zasadniczo podobny do przykładu Fortune Server dostarczanych przez Qt (http://doc.qt.io/qt-5/qtnetwork-fortuneserver-example.html), ale to, co widzimy jest to, że od czasu do czasu aplikacja jest SEG faulting po wyłączeniu z poniższego śladu stosu (gwint 6 upaść):Jak zapobiec wyścigom podczas wyścigów z klasami Qt Network

Thread 0:: Dispatch queue: com.apple.main-thread 
0 libsystem_kernel.dylib   0x00007fff8deb4fca __open + 10 

Thread 1:: Dispatch queue: com.apple.libdispatch-manager 
0 libsystem_kernel.dylib   0x00007fff8deb6232 kevent64 + 10 
1 libdispatch.dylib    0x00007fff90f0426e _dispatch_mgr_thread + 52 

Thread 2: 
0 libsystem_kernel.dylib   0x00007fff8deb594a __workq_kernreturn + 10 
1 libsystem_pthread.dylib   0x00007fff887833dd start_wqthread + 13 

Thread 3: 
0 libsystem_kernel.dylib   0x00007fff8deb594a __workq_kernreturn + 10 
1 libsystem_pthread.dylib   0x00007fff887833dd start_wqthread + 13 

Thread 4: 
0 libsystem_kernel.dylib   0x00007fff8deb594a __workq_kernreturn + 10 
1 libsystem_pthread.dylib   0x00007fff887833dd start_wqthread + 13 

Thread 5:: Dispatch queue: com.apple.NSXPCConnection.m-user.com.apple.airportd 
0 libsystem_platform.dylib  0x00007fff8923378d _os_lock_handoff_lock + 23 
1 libobjc.A.dylib     0x00007fff83258906 objc_object::sidetable_clearDeallocating() + 64 
2 libobjc.A.dylib     0x00007fff8323e651 objc_destructInstance + 145 
3 libobjc.A.dylib     0x00007fff8323e595 object_dispose + 22 
4 com.apple.CoreFoundation  0x00007fff84eea448 -[__NSArrayM dealloc] + 376 
5 libobjc.A.dylib     0x00007fff8325889c objc_object::sidetable_release(bool) + 236 
6 com.apple.Foundation   0x00007fff85747909 -[_NSXPCInterfaceMethodInfo dealloc] + 63 
7 libobjc.A.dylib     0x00007fff8325889c objc_object::sidetable_release(bool) + 236 
8 com.apple.CoreFoundation  0x00007fff84ed5db0 CFRelease + 304 
9 com.apple.CoreFoundation  0x00007fff84ee5b92 __CFBasicHashDrain + 498 
10 com.apple.CoreFoundation  0x00007fff84ed5e8e CFRelease + 526 
11 com.apple.Foundation   0x00007fff8578dd7a -[NSXPCInterface dealloc] + 28 
12 libobjc.A.dylib     0x00007fff8325889c objc_object::sidetable_release(bool) + 236 
13 com.apple.Foundation   0x00007fff8578df0c -[NSXPCConnection dealloc] + 281 
14 libobjc.A.dylib     0x00007fff8325889c objc_object::sidetable_release(bool) + 236 
15 libsystem_blocks.dylib   0x00007fff8d3166e5 _Block_release + 196 
16 libdispatch.dylib    0x00007fff90effe73 _dispatch_client_callout + 8 
17 libdispatch.dylib    0x00007fff90f035cd _dispatch_queue_drain + 1100 
18 libdispatch.dylib    0x00007fff90f03030 _dispatch_queue_invoke + 202 
19 libdispatch.dylib    0x00007fff90f02bef _dispatch_root_queue_drain + 463 
20 libdispatch.dylib    0x00007fff90f02a1c _dispatch_worker_thread3 + 91 
21 libsystem_pthread.dylib   0x00007fff88785a9d _pthread_wqthread + 729 
22 libsystem_pthread.dylib   0x00007fff887833dd start_wqthread + 13 

Thread 6 Crashed:: Qt bearer thread 
0 org.qt-project.QtNetwork  0x0000000100a541cb QNetworkConfigurationManagerPrivate::~QNetworkConfigurationManagerPrivate() + 107 
1 org.qt-project.QtNetwork  0x0000000100a5431e QNetworkConfigurationManagerPrivate::~QNetworkConfigurationManagerPrivate() + 14 
2 org.qt-project.QtCore   0x0000000100d72427 QObject::event(QEvent*) + 823 
3 org.qt-project.QtCore   0x0000000100d49588 QCoreApplication::notify(QObject*, QEvent*) + 104 
4 org.qt-project.QtCore   0x0000000100d4a212 QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) + 1058 
5 org.qt-project.QtCore   0x0000000100d997db QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 59 
6 org.qt-project.QtCore   0x0000000100d46c1c QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 412 
7 org.qt-project.QtCore   0x0000000100b9c07e QThread::exec() + 110 
8 org.qt-project.QtCore   0x0000000100b9fc02 QThreadPrivate::start(void*) + 338 
9 libsystem_pthread.dylib   0x00007fff8878605a _pthread_body + 131 
10 libsystem_pthread.dylib   0x00007fff88785fd7 _pthread_start + 176 
11 libsystem_pthread.dylib   0x00007fff887833ed thread_start + 13 

Jak widać, wątek 0 jest gotowy - jesteśmy poza głównym. Jestem pewien, że jest jakiś kod porządkowy, którego nie mogę zadzwonić, kiedy pozbywamy się naszych zasobów, ale nie wiem, co to może być.

Bez wprowadzenie wszystkie nasze źródła tu podstawowa sieć połączeń robiły to:

class RestServer : public QObject { 
RestServer::RestServer() { 
    _tcpServer = new QTcpServer(this); 
} 

void RestServer::listen(quint16 port) 
{ 
    if (!_tcpServer->listen(QHostAddress::LocalHost, port)) { 
     LOG_ERROR("RestServer", "Failed to start server at: " << port); 
     throw std::exception(); 
    } 
    _portNum = _tcpServer->serverPort(); 
    LOG_INFO("RestServer", "Server is listening at: " << _portNum); 
    connect(_tcpServer, SIGNAL(newConnection()), this, SLOT(connectSocket())); 
} 

Wtedy w naszym kodzie testowym, my w zasadzie zrobić:

void RestAPIServer_test::responseCallback(QNetworkReply *reply) 
{ 
    auto response = reply->readAll(); 
    _uri = response; 

    reply->close(); 

    QCoreApplication::exit(); 
} 

TEST_F(RestAPIServer_test, urlWithPercents) 
{ 
    RestServer restServer(); 
    restServer.listen(0); 
    quint16 port = restServer.serverPort(); 

    // "widget/foo bar.txt" 
    QUrl serviceUrl(QString("http://localhost:%1/path/?path=widget%2Ffoo%20bar.txt").arg(port)); 

    QNetworkAccessManager networkManager(this); 
    connect(&networkManager, SIGNAL(finished(QNetworkReply*)), this, SLOT(responseCallback(QNetworkReply*))); 

    QNetworkRequest request(serviceUrl); 
    request.setHeader(QNetworkRequest::ContentTypeHeader, "application/x-www-form-urlencoded"); 
    networkManager.get(request); 

    QCoreApplication::exec(); 

    ASSERT_EQ(QString("path=widget/foo bar.txt"), _uri); 
} 

Odpowiedz

0

Problem wydawał się być z powodu pewnych wątków związanych z siecią stworzonych przez Qt nadal działa na trochę po wywołaniu do QCoreApplication :: quit() zostało wywołane, prawdopodobnie dlatego, że funkcja quit() została wywołana z funkcji wywołania zwrotnego zarejestrowanej przez QTcpSocket. Rozwiązaniem było umieścić 1-sekundowy sen po wywołaniu wyjść:

void RestAPIServer_test::responseCallback(QNetworkReply *reply) 
{ 
    auto response = reply->readAll(); 
    _uri = response; 

    reply->close(); 

    QCoreApplication::exit(); 

    // This prevents a shutdown race condition where Qt service 
    // threads continue to run after the call to exit(). 
    std::this_thread::sleep_for(std::chrono::milliseconds(1000)); 
} 
0

To nie jest bezpieczne stwórz na stacku QObject z rodzicem. Spójrz na linię

Obiekt zostanie zniszczony dwukrotnie, co nie jest możliwe, więc widzisz awarię. Zmień tę linię następująco (oczywiście, stosowanie zmiennej networkManager musi być aktualizowana):

QNetworkAccessManager* networkManager=new QNetworkAccessManager(this); 
+0

Dzięki za cynk. W rzeczywistości poprzednia wersja tego przykładu działała dokładnie tak, jak mówiłaś, ale w tym przypadku zmieniłem ją na zmienną stosu, aby sprawdzić, czy problem wynikał z tego, że menedżer sieci żył poza zakresem tego kodu. W obu przypadkach pojawia się sporadyczne uszkodzenie. –

+0

Jak wywołać 'quit()' na 'QCoreApplication', aby zatrzymać pętlę' exec() '? Sugerowałbym wstawienie w tym miejscu gniazda proxy pomiędzy twoim sygnałem i 'quit()', w którym możesz spróbować zniszczyć swój serwer i menedżera dostępu do sieci jawnie. Następnie możesz wypromować sygnał do 'quit()' bezpośrednio albo używając 'QTimer :: singleShot()' aby upewnić się, że wszystkie wątki sieciowe są poprawnie zakończone. Zobacz, jaki otrzymasz wynik. –

+0

"Tworzenie obiektu QObject na stosie z rodzicem nie jest bezpieczne" - jest to prawdą tylko wtedy, gdy rodzic może zostać usunięty przed obiektem na stosie, w przeciwnym razie obiekt zostanie usunięty z listy rodzica dzieci po zniszczeniu, brak podwójnego usunięcia –