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
Crash in OCC::DiscoveryJob::remote_vio_readdir_hook #3051
Comments
Looking at my code again I wonder what could cause this. In theory all deletions should happen properly afterwards.. |
This all happen in a secondary thread, is there any data shared that might need some locking in that area? |
Yes, the data is owned by |
Looking at the disassembly, what seems to happen is that our QLinkedList<csync_vio_file_stat_t*>::iterator::i == 0. The weird thing is that the QLinkedList always seem to return iterators pointing to one of its node (or at end(), which points to the root QLinkedListData*). So the only way that this could happen is with a default constructed QLinkedList<>::iterator, e.g. if we pass a DiscoveryDirectoryResult without setting DiscoveryDirectoryResult::iterator to the list's begin(). I'm trying to find out if that can actually happen, let me know if this rings a bell. |
Somehow Or the wait condition in |
I just had a quick look at the code. In DiscoveryMainThread::abort:
Why is it tryLock here? What if it fails? than it is not aborted? |
…::iterator #3051 The default constructor of the iterator points to NULL, which makes it != end() but invalid to dereference. Use an integer index instead to keep 0 as a valid default value that can always correctly be checked against size(). Also make sure that no data is shared between threads by making the csync_vio_file_stat_t copyable and passing it as const.
In some cryptic cases where the getetag property wasn't returned by the server, we might be trying to c_strdup a null pointer in csync_vio_file_stat_copy. At least avoid crashing in this case by looking for CSYNC_VIO_FILE_STAT_FIELDS_ETAG, like csync_vio_file_stat_destroy does.
Those two commits should fix this one, and again we won't really know until the next release. Closing for now. |
Found 72 similar crash reports.
The text was updated successfully, but these errors were encountered: