Deleting the QLocalSocket while iterating the QList with qDeleteAll
would trigger onLostConnection, which would modify the list mid-air
and leave dangling pointers in it.
Calling save() in the CookieJar destructor was problematic. For instance
we sometimes create a new QNAM with a new CookieJar and then call
setCookieJar() on it to assign some other jar. That destroy the fresh
jar and potentially overwrite cookies.
Also explicitly saving the account's cookies when the account is saved
is more explicit and thus more reliable than counting on the Account
destructor to do it.
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.
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.
The config currently only disable the reporter, but still leaves
the crash handler installed on startup. This causes conflicts
when running those builds in lldb.
Work around the issue by requiring the crash reporter to be
disabled in the settings before owncloud can be run in lldb.
This has the negative side-effect of not covering the
initial ConfigFile loading with the crash handler.
Issue #2946
