oc-2024 - sync client 1.1 crashing on Linux (and v1.1.1)

[msrex]

From http://bugs.owncloud.org/thebuggenie/owncloud/issues/oc-2024

Am unable to replicate with v1.1.3. Nevertheless the reporter put quite some good info and feedback in the report, so I wanted to make sure it is seen by people.

Description:
There were a couple reports of the sync client 1.1 crashing on OSX, but nothing about Linux. I'm seeing the same w/OSX and also under Linux. I didn't want to pollute an OSX bug report with Linux info, but feel free to merge or mark this as a duplicate if that makes the most sense.

Since upgrading to the csync client 1.1 under Linux, I've been unable to complete even a single sync. I am running 4.5 on the servers side. The first thing I observed since upgrading was the creation of a HUGE number of files under /tmp with names like csync.. They chewed up about 7Gb worth of space trying to sync about 16Gb of data. The last thing I see in the log owncloud log file is:

csync.owncloud - Putting file through file cache.

and in the debugger I see

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `/usr/bin/owncloud --logfile /home/mkd/tmp/owncloud.log'. Program terminated with signal 13, Broken pipe.

0 0x00007ffff55e1ac3 in *__GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87

87 ../sysdeps/unix/sysv/linux/poll.c: No such file or directory.

I do have a core file, but I'm not convinced it's of use given the last warning above. I'd be happy to help debug if you can give me a few pointers.

Thanks!

Mark

Reproduction steps:
Just try and sync using the 1.1 version of the client under Linux.
#2 Comment posted by Mark Oct 19, 19:45

I think I tracked down one cause of my crash under Linux. During a sync w/the OC 1.1 client, it creates a bunch of csync. files under /tmp. With my test environment, this results in > 30Gb of files, which is larger than my /tmp directory can handle. What purpose do these files play in the sync? If they are truly temporary, then they should go away, right? If they aren't, then perhaps /tmp is not the place to store them... at least under debian, /tmp is wiped during each boot. It might also be helpful to have the client dump something in the log that mentions it can't write files in /tmp rather than just stop logging and have the client die.

I actually thought this was the only cause, but as I was writing this update the client crashed again. This time, I have 78G of free space, so I'm sure this wasn't the only cause of the crash.
#3 Comment posted by Mark Oct 22, 20:29

I upgraded to OC 1.1.1 since filing this bug, but experienced another segfault. Here what I could get of a backtrace, I'm using the debian binary package.

0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:32
1 0x00007ffff604bc76 in c_strdup () from /usr/lib/libocsync.so.0
2 0x00007ffff60449f5 in ?? () from /usr/lib/libocsync.so.0
3 0x00007ffff604da06 in ?? () from /usr/lib/libocsync.so.0
4 0x00007ffff604da19 in ?? () from /usr/lib/libocsync.so.0
5 0x00007ffff604d9f1 in ?? () from /usr/lib/libocsync.so.0
6 0x00007ffff604da19 in ?? () from /usr/lib/libocsync.so.0
7 0x00007ffff604da19 in ?? () from /usr/lib/libocsync.so.0
8 0x00007ffff604d9f1 in ?? () from /usr/lib/libocsync.so.0
9 0x00007ffff604d9f1 in ?? () from /usr/lib/libocsync.so.0
10 0x00007ffff604da19 in ?? () from /usr/lib/libocsync.so.0
11 0x00007ffff604da19 in ?? () from /usr/lib/libocsync.so.0
12 0x00007ffff604d9f1 in ?? () from /usr/lib/libocsync.so.0
13 0x00007ffff604da9b in c_rbtree_walk () from /usr/lib/libocsync.so.0
14 0x00007ffff6040fc8 in csync_destroy () from /usr/lib/libocsync.so.0
15 0x00007ffff628ad4d in Mirall::CSyncThread::startSync() ()

from /usr/lib/libowncloudsync.so

16 0x00007ffff6299054 in Mirall::CSyncThread::qt_metacall(QMeta Object::Call, int, void**) () from /usr/lib/libowncloudsync.so
17 0x00007ffff663ba2e in QObject::event(QEvent*) ()

from /usr/lib/x86_64-linux-gnu/libQtCore.so.4

18 0x00007ffff730370c in QApplication Private::notify_helper(QObject*, QEvent*)

() from /usr/lib/x86_64-linux-gnu/libQtGui.so.4

19 0x00007ffff7307b8a in QApplication::notify(QObject*, QEvent*) ()

from /usr/lib/x86_64-linux-gnu/libQtGui.so.4

20 0x00007ffff6626b5e in QCore Application::notifyInternal(QObject*, QEvent*)

() from /usr/lib/x86_64-linux-gnu/libQtCore.so.4

21 0x00007ffff662a9e1 in QCore Application Private::sendPostedEvents(QObject*, int, QThread Data*) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
22 0x00007ffff66550e3 in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
23 0x00007ffff4bf9355 in g_main_context_dispatch ()

from /lib/x86_64-linux-gnu/libglib-2.0.so.0

24 0x00007ffff4bf9688 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
25 0x00007ffff4bf9744 in g_main_context_iteration ()

from /lib/x86_64-linux-gnu/libglib-2.0.so.0

26 0x00007ffff6655276 in QEvent Dispatcher Glib::processEvents(QFlags<QEvent Loop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
27 0x00007ffff66258af in QEvent Loop::processEvents(QFlags<QEvent Loop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
28 0x00007ffff6625b38 in QEvent Loop::exec(QFlags<QEvent Loop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
29 0x00007ffff6528d70 in QThread::exec() ()

from /usr/lib/x86_64-linux-gnu/libQtCore.so.4

30 0x00007ffff652bd0b in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
31 0x00007ffff50c7b50 in start_thread (arg=<optimized out>)

at pthread_create.c:304

32 0x00007ffff55ec70d in clone ()

at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112

Let me know if you need something better to help track this down. In particular, hints as to how to enable debugging symbols with the debian package would be awesome.

Thanks!

Mark

[danimo]

Duplicate of #154