This is largely a guess, but this is the only place where we use
a QIODevice to push data through QNAM and that the QIODevice isn't
a direct child of the QNetworkReply.
Fix the issue by making sure that we don't go back to the event loop
and possibly handle network events between the destruction of the
upload QIODevice and the QNetworkReply, which might lead to QNAM
dereferencing a dangling QIODevice pointer.
Make sure that we define NDEBUG in all configurations.
Also remove inconsistent defines:
WIN32: We don't use
_DEBUG;_WINDOWS;_USRDLL: Should be defined by the compiler if necessary
OCCONTEXTMENU_EXPORTS: We currently don't use dllimport anyway
This also update the binary submodule with an updated build.
The QNetworkAccessManager is reset when we are disconnected, just
before attempting to fetch the server's status.php.
This may help fix the problem described in various issues where we
get 'Connection closed' or timeout errors after the OS has woken
from sleep.
Since each new connection to the socket API would trigger a broadcast
of REGISTER_PATH to all existing connections, opening the context menu
would trigger a SHChangeNotify call of the root directory through
the overlay icon extension, which is currently also connected to the
socket API, waiting for changes.
Fix the issue by sending the initial REGISTER_PATH automatic response
only to the connecting socket.
This moves the crash handler installation during the OCC::Application
contruction. This still leaves a window where crashes wouldn't be
caught, leaving the QtSingleApplication and theme initialization
code unreported, but isn't requiring any refactoring for now.
Issue #2952
It was not emitted when a removed folder finished its sync,
and that left the UI in an old state sometimes.
Removing the Folder explicitly is unnecessary as a QSignalMapper
will automatically remove mappings for deleted QObjects.
