Skip to content
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

Closed
jturcotte opened this issue Mar 30, 2015 · 7 comments
Closed

Crash in OCC::DiscoveryJob::remote_vio_readdir_hook #3051

jturcotte opened this issue Mar 30, 2015 · 7 comments

Comments

@jturcotte
Copy link
Member

Thread 21 (crashed)
 0  libowncloudsync.dll!OCC::DiscoveryJob::remote_vio_readdir_hook [discoveryphase.cpp : 470 + 0x0]
    eip = 0x6a558c51   esp = 0x07bbcfc0   ebp = 0x07001590   ebx = 0x09c5cfe8
    esi = 0x00000001   edi = 0x07051203   eax = 0x09c5d328   ecx = 0x09c5d328
    edx = 0x00000000   efl = 0x00010297
    Found by: given as instruction pointer in context
 1  libocsync.dll!csync_ftw [csync_update.c : 641 + 0x10]
    eip = 0x633c6d42   esp = 0x07bbd000   ebp = 0x07001590   ebx = 0x09a550cb
    esi = 0x00000001   edi = 0x07051203
    Found by: call frame info
 2  libocsync.dll!csync_ftw [csync_update.c : 784 + 0x26]
    eip = 0x633c6f71   esp = 0x07bbd150   ebp = 0x07001590   ebx = 0x09cf7ad8
    esi = 0x00000001   edi = 0x06ea4f38
    Found by: call frame info
 3  libocsync.dll!csync_ftw [csync_update.c : 784 + 0x26]
    eip = 0x633c6f71   esp = 0x07bbd2a0   ebp = 0x07001590   ebx = 0x09cf8aa8
    esi = 0x00000001   edi = 0x06ea4e48
    Found by: call frame info
 4  libocsync.dll!csync_ftw [csync_update.c : 784 + 0x26]
    eip = 0x633c6f71   esp = 0x07bbd3f0   ebp = 0x07001590   ebx = 0x09bb9268
    esi = 0x00000001   edi = 0x06ea5280
    Found by: call frame info
 5  libocsync.dll!csync_ftw [csync_update.c : 784 + 0x26]
    eip = 0x633c6f71   esp = 0x07bbd540   ebp = 0x07001590   ebx = 0x06fc62f0
    esi = 0x00000001   edi = 0x06ea5550
    Found by: call frame info
 6  libocsync.dll!csync_ftw [csync_update.c : 784 + 0x26]
    eip = 0x633c6f71   esp = 0x07bbd690   ebp = 0x07001590   ebx = 0x06fc6ed0
    esi = 0x00000001   edi = 0x0a390340
    Found by: call frame info
 7  libocsync.dll!csync_ftw [csync_update.c : 784 + 0x26]
    eip = 0x633c6f71   esp = 0x07bbd7e0   ebp = 0x07001590   ebx = 0x00000000
    esi = 0x00000001   edi = 0x0a3903b8
    Found by: call frame info
 8  libocsync.dll!csync_update [csync.c : 250 + 0x1f]
    eip = 0x633c2701   esp = 0x07bbd930   ebp = 0x07001590   ebx = 0x07bbd950
    esi = 0x07bbd958   edi = 0x000054ec
    Found by: call frame info
 9  libowncloudsync.dll!OCC::DiscoveryJob::start [discoveryphase.cpp : 508 + 0xb]
    eip = 0x6a557e94   esp = 0x07bbd980   ebp = 0x07bbda08   ebx = 0x0704c890
    esi = 0x0704c890   edi = 0x00000005
    Found by: call frame info
10  libowncloudsync.dll!OCC::DiscoveryJob::qt_static_metacall [moc_discoveryphase.cpp : 433 + 0xf]
    eip = 0x6a5d962f   esp = 0x07bbd9a0   ebp = 0x07bbda08   ebx = 0x09a7aed8
    esi = 0x0704c890   edi = 0x00000005
    Found by: call frame info
11  Qt5Core.dll!QMetaCallEvent::placeMetaCall [qobject.cpp : 485 + 0x1d]
    eip = 0x66b1c879   esp = 0x07bbda10   ebp = 0x07bbdb18   ebx = 0x09a7aed8
    esi = 0x0704c890   edi = 0x00000005
    Found by: call frame info
12  Qt5Core.dll!QObject::event [qobject.cpp : 1245 + 0x14]
    eip = 0x66b1fec9   esp = 0x07bbda40   ebp = 0x07bbdb18   ebx = 0x0704c890
    esi = 0x09a7aed8   edi = 0x044aa640
    Found by: call frame info
13  Qt5Widgets.dll!QApplicationPrivate::notify_helper [qapplication.cpp : 3722 + 0xa]
    eip = 0x00afae9a   esp = 0x07bbdb20   ebp = 0x0028fe30   ebx = 0x0704c890
    esi = 0x09a7aed8   edi = 0x044aa640
    Found by: call frame info
14  Qt5Widgets.dll!QApplication::notify [qapplication.cpp : 3505 + 0x17]
    eip = 0x00afff77   esp = 0x07bbdb50   ebp = 0x0028fe30   ebx = 0x00000000
    esi = 0x00000401   edi = 0x09a7aed8
    Found by: call frame info
15  Qt5Core.dll!QCoreApplication::notifyInternal [qcoreapplication.cpp : 932 + 0x1a]
    eip = 0x66af6c00   esp = 0x07bbdcc0   ebp = 0x07bbdd28   ebx = 0x0704a540
    esi = 0x0000002b   edi = 0x00000000
    Found by: call frame info
16  Qt5Core.dll!QCoreApplicationPrivate::sendPostedEvents [qcoreapplication.h : 228 + 0x2a]
    eip = 0x66afb98e   esp = 0x07bbdd30   ebp = 0x07bbdde8   ebx = 0x0704a540
    esi = 0x0000002b   edi = 0x00000000
    Found by: call frame info
17  Qt5Core.dll!QEventDispatcherWin32::sendPostedEvents [qeventdispatcher_win.cpp : 1202 + 0x1e]
    eip = 0x66b48cd1   esp = 0x07bbddf0   ebp = 0x07bbdeb8   ebx = 0x00000000
    esi = 0x00000401   edi = 0x66b4bd90
    Found by: call frame info
18  Qt5Core.dll!qt_internal_proc [qeventdispatcher_win.cpp : 412 + 0x10]
    eip = 0x66b4c09f   esp = 0x07bbde10   ebp = 0x07bbdeb8   ebx = 0x00000000
    esi = 0x00000401   edi = 0x66b4bd90
    Found by: call frame info
19  user32.dll + 0x8e71
    eip = 0x778a8e71   esp = 0x07bbdec0   ebp = 0x07bbdeec
    Found by: previous frame's frame pointer
20  user32.dll + 0x90d1
    eip = 0x778a90d1   esp = 0x07bbdef4   ebp = 0x07bbdf80
    Found by: previous frame's frame pointer
21  user32.dll + 0xa66f
    eip = 0x778aa66f   esp = 0x07bbdf88   ebp = 0x07bbdfec
    Found by: previous frame's frame pointer
22  user32.dll + 0xa6e0
    eip = 0x778aa6e0   esp = 0x07bbdff4   ebp = 0x07bbdff8
    Found by: previous frame's frame pointer
23  Qt5Core.dll!QEventDispatcherWin32::processEvents [qeventdispatcher_win.cpp : 806 + 0x9]
    eip = 0x66b4b6b7   esp = 0x07bbe000   ebp = 0x07bbfde8
    Found by: previous frame's frame pointer
24  Qt5Core.dll!QEventLoop::exec [qeventloop.cpp : 128 + 0x14]
    eip = 0x66af5b68   esp = 0x07bbfdf0   ebp = 0x07bbfe88
    Found by: previous frame's frame pointer
25  Qt5Core.dll!QThread::exec [qthread.cpp : 503 + 0x16]
    eip = 0x6695b4b5   esp = 0x07bbfe90   ebp = 0x07bbff08   ebx = 0x0a3aa8bc
    esi = 0x06fdf9a8
    Found by: call frame info
26  Qt5Core.dll!QThreadPrivate::start [qthread_win.cpp : 344 + 0x7]
    eip = 0x6695f5ee   esp = 0x07bbff10   ebp = 0x07bbff38   ebx = 0x0a3aa8bc
    esi = 0x06fdf9a8
    Found by: call frame info
27  msvcrt.dll + 0x17fb0
    eip = 0x77077fb0   esp = 0x07bbff40   ebp = 0x07bbff78
    Found by: previous frame's frame pointer
28  msvcrt.dll + 0x180f5
    eip = 0x770780f5   esp = 0x07bbff80   ebp = 0x07bbff80
    Found by: previous frame's frame pointer
29  kernel32.dll + 0x17c04
    eip = 0x76ed7c04   esp = 0x07bbff88   ebp = 0x07bbff94
    Found by: previous frame's frame pointer
30  ntdll.dll + 0x5b54f
    eip = 0x77e7b54f   esp = 0x07bbff9c   ebp = 0x07bbffdc
    Found by: previous frame's frame pointer
31  ntdll.dll + 0x5b51a
    eip = 0x77e7b51a   esp = 0x07bbffe4   ebp = 0x07bbffec
    Found by: previous frame's frame pointer

Found 72 similar crash reports.

@guruz
Copy link
Contributor

guruz commented Mar 30, 2015

Looking at my code again I wonder what could cause this. In theory all deletions should happen properly afterwards..

@jturcotte
Copy link
Member Author

This all happen in a secondary thread, is there any data shared that might need some locking in that area?

@guruz
Copy link
Contributor

guruz commented Mar 31, 2015

Yes, the data is owned by DiscoveryMainThread object (_directoryContents). I'm thinking a bit right now that it borks with _currentDiscoveryDirectoryResult but that should not happen either..
Or somehow related to abort.

@jturcotte
Copy link
Member Author

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.

@guruz
Copy link
Contributor

guruz commented Apr 2, 2015

Somehow DiscoveryMainThread::singleDirectoryJobFinishedWithErrorSlot?
or DiscoveryMainThread::abort() (which however should probably not make the csync vio hook call be done at all)

Or the wait condition in DiscoveryJob::remote_vio_opendir_hook being woken up without the DiscoveryDirectoryResult being actually filled? although then code should be EIO and it would return NULL to the hook and then not call the remote_vio_readdir_hook

@ogoffart
Copy link
Contributor

ogoffart commented Apr 6, 2015

I just had a quick look at the code.

In DiscoveryMainThread::abort:

        if (_discoveryJob->_vioMutex.tryLock()) {

Why is it tryLock here? What if it fails? than it is not aborted?

jturcotte added a commit that referenced this issue Apr 8, 2015
…::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.
jturcotte added a commit that referenced this issue Apr 8, 2015
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.
@jturcotte
Copy link
Member Author

Those two commits should fix this one, and again we won't really know until the next release. Closing for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants