-
-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Interface crashes on bad WiFi #1119
Comments
Problem 1;
|
Problem 2:
|
Looked at the code, poked around... my conclusion is that QUdpSocket isn't thread safe but we're using the same socket from several threads at once for whatever reason, and shouldn't be doing that. setError is very simple code that doesn't try to do any kind of thread safety, and there doesn't seem to be anything up the chain either: https://code.qt.io/cgit/qt/qtbase.git/tree/src/network/socket/qabstractsocket.cpp?h=5.15#n1462 That it only blows up in setError() is probably because there's not that much to a socket and an internal QString is the one fiddly bit that has a tendency to blow up. The problem probably manifests in other ways that don't crash. The reason why it only happens on unreliable connections is because network errors invoke the code that exercise this path. |
Further investigation: In SendQueue::create, in SendQueue.cpp we hand off an existing socket to a thread. I thought this was a Qt object, but it's actually ours, udt::Socket. And it already has some provisions for locking:
Looks like we need a third lock for the inner socket (which may be UDP or WebRTC). And that should neatly solve the issue. |
It crashes with:
The text was updated successfully, but these errors were encountered: