Can't sync

[schleumer]

I'm trying to sync a library(it's a big one) and i'm getting the following errors on the logs which i believe is not letting me sync my libraries:

ccnet.log

[02/16/16 18:27:36] ../common/session.c(418): Listen on 127.0.0.1 13419
[02/16/16 18:27:36] ../common/session.c(290): Update pubinfo file
[02/16/16 18:27:37] ../common/session.c(398): Accepted a local client
[02/16/16 18:27:37] ../common/session.c(398): Accepted a local client
[02/16/16 18:27:37] ../common/session.c(398): Accepted a local client
[02/16/16 18:27:37] ../common/session.c(398): Accepted a local client
[02/16/16 18:27:37] ../common/session.c(398): Accepted a local client
[02/16/16 18:27:37] ../common/session.c(398): Accepted a local client
[02/16/16 18:27:39] ../common/session.c(398): Accepted a local client
[02/16/16 18:27:52] ../common/session.c(398): Accepted a local client
[02/16/16 18:31:23] ../common/peer.c(941): libevent got an error! what=33, errno=0 (No error)
[02/16/16 18:31:23] ../common/peer.c(943): Local peer down
[02/16/16 18:31:23] ../common/peer.c(941): libevent got an error! what=33, errno=0 (No error)
[02/16/16 18:31:23] ../common/peer.c(943): Local peer down
[02/16/16 18:31:23] ../common/peer.c(941): libevent got an error! what=33, errno=0 (No error)
[02/16/16 18:31:23] ../common/peer.c(943): Local peer down

seafile.log

[02/16/16 18:27:37] seaf-daemon.c(533): starting seafile client 5.0.4
[02/16/16 18:27:37] seaf-daemon.c(535): seafile source code version 5c3f82c04016287affd14ecea390365b1cd3217d
[02/16/16 18:27:37] ../common/mq-mgr.c(60): [mq client] mq cilent is started
[02/16/16 18:27:39] ../common/mq-mgr.c(106): [mq mgr] publish to hearbeat mq: seafile.heartbeat
[02/16/16 18:28:02] clone-mgr.c(819): Transition clone state for 5a29509c from [init] to [connect].
[02/16/16 18:28:03] [02/16/16 18:28:03] http-tx-mgr.c(4011): Download with HTTP sync protocol version 1.
clone-mgr.c(819): Transition clone state for 5a29509c from [connect] to [fetch].
[02/16/16 18:28:03] http-tx-mgr.c(1006): Transfer repo '5a29509c': ('normal', 'init') --> ('normal', 'check')
[02/16/16 18:28:03] http-tx-mgr.c(1006): Transfer repo '5a29509c': ('normal', 'check') --> ('normal', 'commit')
[02/16/16 18:28:03] http-tx-mgr.c(1006): Transfer repo '5a29509c': ('normal', 'commit') --> ('normal', 'fs')
[02/16/16 18:31:19] http-tx-mgr.c(1006): Transfer repo '5a29509c': ('normal', 'fs') --> ('normal', 'data')
[02/16/16 18:31:22] repo-mgr.c(4649): File ~some file~ is updated by user. Will checkout to conflict file later.
[02/16/16 18:31:23] repo-mgr.c(4649): File ~some file~ is updated by user. Will checkout to conflict file later.

applet.log

[02/16/16 18:35:26][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:26][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:26][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:26][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:26][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:26][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:26][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:26][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:27][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:27][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:27][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:27][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:27][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:27][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:27][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:27][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:28][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:28][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:28][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:28][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:28][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:28][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:28][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:28][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:29][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:29][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:29][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:29][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:29][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:29][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:29][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:29][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:30][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:30][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:30][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:30][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:30][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:30][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:30][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:30][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:31][Sea RPC] Bad response: 102 processor is dead.
[02/16/16 18:35:31]failed to get repo list: Transport Error

[adrianimboden]

I have the same problem here. I installed the git master, to find out a little bit more, but did not find out anything (never looked into the source of Seafile before).

git revisions (pretty current I think): seafile: 0ff7889fdfec68f3559e51b4605f8348a758c34b libsearpc: 13f49676cc5444d3a9e9397310f7d322fb7d887f seafile-client: cecd90093f680af1533c433d5dd4891c69364668 ccnet: b3935dce8e9a6cfd3b9f99412e831e51747280dc

Server version: seafile-server-5.0.4

I have windows clients too, but these don't have any problems. If I can help, I will gladly do so. The problem is pretty annoying.

My logs look like this: ccnet.log (client)

[02/18/16 19:49:32] ../common/peer.c(943): Local peer down
[02/18/16 19:49:32] ../common/peer.c(943): Local peer down
[02/18/16 19:49:32] ../common/peer.c(943): Local peer down
[02/18/16 19:49:38] ccnet-daemon.c(193): starting ccnet client 1.4.2
[02/18/16 19:49:38] ../common/session.c(132): using config file /home/adrian/.ccnet/ccnet.conf
[02/18/16 19:49:38] ../common/session.c(455): socket file exists, delete it anyway
[02/18/16 19:49:38] ../common/session.c(484): Listen on /home/adrian/.ccnet/ccnet.sock for local clients
[02/18/16 19:49:38] ../common/session.c(290): Update pubinfo file
[02/18/16 19:49:39] ../common/session.c(398): Accepted a local client
[02/18/16 19:49:39] ../common/session.c(398): Accepted a local client
[02/18/16 19:49:39] ../common/session.c(398): Accepted a local client
[02/18/16 19:49:39] ../common/session.c(398): Accepted a local client
[02/18/16 19:49:39] ../common/session.c(398): Accepted a local client
[02/18/16 19:49:39] ../common/session.c(398): Accepted a local client
[02/18/16 19:49:39] ../common/processors/rcvcmd-proc.c(492): Add server b593ee88 sync.svc.firenet.ch:10001
[02/18/16 19:49:39] ../common/connect-mgr.c(364): [Conn] Start outgoing connect to (null)(b593ee88e0) 10.10.48.109:10001
[02/18/16 19:49:39] ../common/connect-mgr.c(289): [Conn] Peer (null) (b593ee88e0) connected
[02/18/16 19:49:40] ../common/session.c(398): Accepted a local client
[02/18/16 22:48:27] ../common/peer.c(943): Local peer down
[02/18/16 22:48:27] ../common/peer.c(943): Local peer down
[02/18/16 22:48:27] ../common/peer.c(943): Local peer down
### <- here i attached the debugger to look around a bit, but not even the network timeout let it recover from not syncing afterwards
[02/19/16 22:23:41] ../common/peer.c(949): [Net Error] Peer Firenet (b593ee88e0) down
[02/19/16 22:24:48] ../common/connect-mgr.c(289): [Conn] Peer Firenet (b593ee88e0) connected

seafile.log (client)

[02/18/16 19:49:39] seaf-daemon.c(519): starting seafile client 5.0.3
[02/18/16 19:49:39] ../common/mq-mgr.c(60): [mq client] mq cilent is started
[02/18/16 19:49:39] ../common/mq-mgr.c(106): [mq mgr] publish to hearbeat mq: seafile.heartbeat
[02/18/16 19:49:41] sync-mgr.c(660): Repo 'Repo4' sync state transition from 'synchronized' to 'committing'.
[02/18/16 19:49:41] repo-mgr.c(3249): All events are processed for repo 6e00afaf-3974-4fb9-b88e-91f9cf2772fe.
[02/18/16 19:49:41] sync-mgr.c(660): Repo 'Repo4' sync state transition from 'committing' to 'initializing'.
[02/18/16 19:49:41] http-tx-mgr.c(1611): Bad response code for GET https://sync.local/seafhttp/repo/folder-perm: 404.
[02/18/16 19:49:41] http-tx-mgr.c(1893): Bad response code for GET https://sync.local/seafhttp/repo/locked-files: 404.
[02/18/16 19:49:42] sync-mgr.c(660): Repo 'Repo1' sync state transition from 'synchronized' to 'committing'.
[02/18/16 19:49:42] repo-mgr.c(3249): All events are processed for repo bba4dacd-7f3f-44bd-a1fe-279a4ba092cb.
[02/18/16 19:49:42] sync-mgr.c(660): Repo 'Repo1' sync state transition from 'committing' to 'initializing'.
[02/18/16 19:49:43] sync-mgr.c(660): Repo 'Repo2' sync state transition from 'synchronized' to 'committing'.
[02/18/16 19:49:43] repo-mgr.c(3249): All events are processed for repo 79d3c94a-fefd-47ee-92fd-29faab7c0439.
[02/18/16 19:49:43] sync-mgr.c(660): Repo 'Repo2' sync state transition from 'committing' to 'initializing'.
[02/18/16 19:49:44] sync-mgr.c(660): Repo 'Repo3' sync state transition from 'synchronized' to 'committing'.
[02/18/16 19:49:44] repo-mgr.c(3249): All events are processed for repo 61afffe8-0a03-48b6-aa6a-4c0bb2c8b70c.
[02/18/16 19:49:44] sync-mgr.c(660): Repo 'Repo3' sync state transition from 'committing' to 'initializing'.

applet.log (client)

[02/18/16 19:49:32][Daemon Mgr] stopping ccnet/seafile daemon
[02/18/16 19:49:38]starting ccnet:  ("-c", "/home/adrian/.ccnet") 
[02/18/16 19:49:39]trying to connect to ccnet daemon...
[02/18/16 19:49:39]connected to ccnet daemon
[02/18/16 19:49:39]starting seaf-daemon:  ("-c", "/home/adrian/.ccnet", "-d", "/home/adrian/Seafile/.seafile-data", "-w", "/home/adrian/Seafile") 
[02/18/16 19:49:39]seafile daemon is now running
[02/18/16 19:49:39][Rpc Client] connected to daemon
[02/18/16 19:49:39][MessageListener] connected to daemon
[02/18/16 19:49:39]Unable to get config (int) value download_limit
[02/18/16 19:49:39]Unable to get config (int) value upload_limit
[02/18/16 19:49:40]QString::arg: Argument missing: &Open cloud file browser, Seafile
[02/18/16 19:49:40][Rpc Client] connected to daemon
[02/18/16 19:49:40]The latest version is 5.0.1
[02/18/16 22:48:28][Sea RPC] Bad response: 515 peer down.
[02/18/16 22:48:28][Sea RPC] Bad response: 102 processor is dead.
.... much more (no recover after 24h.

ccnet.log (server), adrian@ada1934d2a2a is the peer from the log above

[02/18/16 19:49:30] ../common/peer.c(949): [Net Error] Peer adrian@adilappy (7b1456632e) down
[02/18/16 19:49:30] ../common/processors/keepalive2-proc.c(475): [Keepalive] Error from peer 515 peer down
[02/18/16 19:49:32] ../common/peer.c(949): [Net Error] Peer adrian@ada1934d2a2a (91ac0ffada) down
[02/18/16 19:49:32] ../common/processors/keepalive2-proc.c(475): [Keepalive] Error from peer 515 peer down
[02/18/16 19:49:35] ../common/connect-mgr.c(289): [Conn] Peer adrian@adilappy (7b1456632e) connected
[02/18/16 19:49:38] ../common/session.c(398): Accepted a local client
[02/18/16 19:49:38] ../common/session.c(398): Accepted a local client
[02/18/16 19:49:38] ../common/peer.c(943): Local peer down
[02/18/16 19:49:38] ../common/peer.c(943): Local peer down
[02/18/16 19:49:39] ../common/connect-mgr.c(289): [Conn] Peer adrian@ada1934d2a2a (91ac0ffada) connected
[02/18/16 19:49:41] ../common/session.c(398): Accepted a local client
[02/18/16 19:49:41] ../common/peer.c(943): Local peer down
[02/18/16 21:04:56] ../common/connect-mgr.c(266): Unknown peer b4113e784ad3070acff6863b8528a6937ae67b3f connecting

[killing]

@schleumer I believe we've solved your issue in the about-to-release 5.0.5 client. Please wait and try it out. @adrianimboden It seems your issue is different from @schleumer . If you can compile the client, could you add debug symbols to seaf-daemon and create core dump? Here is how:

• In the seafile project, use configure "CFLAGS=-g -O0"
• Enable core dump in your system
• Run seafile applet from a command line
• After seaf-daemon crashes, you should see a coredump file in the current directory.
• Use gdb seaf-daemon core.xxx to debug it

[adrianimboden]

Ok, I will do that. I think I will have time for this tomorrow. I didn't see a crash anywhere. Do you want me to create a core dump in the state it is in, when after the error happens?

[killing]

The "102 processor is dead" message indicates seaf-daemon has crashed. Yes a core dump file will be created by the kernel after the error happens.

[adrianimboden]

I could finally reproduce the crash.

It seems, that the program crashes when creating the ssl context.

$ gdb /usr/bin/seaf-daemon pool.core 
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /usr/bin/seaf-daemon...done.
[New LWP 19036]
[New LWP 19034]
[New LWP 8479]
[New LWP 8478]
[New LWP 19035]
[New LWP 19033]

warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `seaf-daemon -c /home/ch1010761/.ccnet -d /home/ch1010761/Seafile/.seafile-data'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007f63544f74d6 in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
(gdb) thread apply all backtrace

Thread 6 (Thread 0x7f6322ffd700 (LWP 19033)):
#0  0x00007f63528be9d3 in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f6352dedee8 in Curl_socket_ready () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#2  0x00007f6352dd9819 in ossl_connect_common () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#3  0x00007f6352ddaf45 in Curl_ossl_connect () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#4  0x00007f6352dee4e9 in Curl_ssl_connect () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#5  0x00007f6352dc5050 in Curl_http_connect () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#6  0x00007f6352dd5efa in Curl_protocol_connect () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#7  0x00007f6352dd61aa in Curl_setup_conn () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#8  0x00007f6352dd6254 in Curl_connect () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#9  0x00007f6352de16d1 in Curl_do_perform () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#10 0x000000000040f818 in http_get (curl=0x7f62f4003dc0, url=0x7f630019b690 "https://sync.svc.firenet.ch/seafhttp/repo/55458891-93be-4a81-99b8-a06e09623c5d/commit/HEAD", token=0x1c09f80 "1b7ba7ba1e011ad398be3ee512d88c5f4221b158", rsp_status=0x7f6322ffcddc, rsp_content=0x7f6322ffcd98, 
    rsp_size=0x7f6322ffcda0, callback=0, cb_data=0x0, timeout=0) at http-tx-mgr.c:698
#11 0x0000000000410ebc in check_head_commit_thread (vdata=0x1bd7710) at http-tx-mgr.c:1246
#12 0x00007f6353fda1d9 in job_thread_wrapper (vdata=0x1bc6760, unused=0x0) at job-mgr.c:54
#13 0x00007f635349b218 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x00007f635349a9b5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#15 0x00007f6352b9ce9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#16 0x00007f63528ca38d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#17 0x0000000000000000 in ?? ()

Thread 5 (Thread 0x7f6347fff700 (LWP 19035)):
#0  0x00007f63528be9d3 in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f6352dedee8 in Curl_socket_ready () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#2  0x00007f6352dd9819 in ossl_connect_common () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#3  0x00007f6352ddaf45 in Curl_ossl_connect () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#4  0x00007f6352dee4e9 in Curl_ssl_connect () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#5  0x00007f6352dc5050 in Curl_http_connect () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#6  0x00007f6352dd5efa in Curl_protocol_connect () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#7  0x00007f6352dd61aa in Curl_setup_conn () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#8  0x00007f6352dd6254 in Curl_connect () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#9  0x00007f6352de16d1 in Curl_do_perform () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#10 0x000000000040f818 in http_get (curl=0x7f6334003800, url=0x7f6314049190 "https://sync.svc.firenet.ch/seafhttp/repo/bba4dacd-7f3f-44bd-a1fe-279a4ba092cb/commit/HEAD", token=0x1b10530 "1b7ba7ba1e011ad398be3ee512d88c5f4221b158", rsp_status=0x7f6347ffeddc, rsp_content=0x7f6347ffed98, 
    rsp_size=0x7f6347ffeda0, callback=0, cb_data=0x0, timeout=0) at http-tx-mgr.c:698
#11 0x0000000000410ebc in check_head_commit_thread (vdata=0x1b10490) at http-tx-mgr.c:1246
#12 0x00007f6353fda1d9 in job_thread_wrapper (vdata=0x1bdad80, unused=0x0) at job-mgr.c:54
#13 0x00007f635349b218 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x00007f635349a9b5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#15 0x00007f6352b9ce9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#16 0x00007f63528ca38d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#17 0x0000000000000000 in ?? ()

Thread 4 (Thread 0x7f6354cbf780 (LWP 8478)):
#0  0x00007f63528caa23 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f6353b9d717 in ?? () from /usr/lib/libevent-2.0.so.5
#2  0x00007f6353b898d7 in event_base_loop () from /usr/lib/libevent-2.0.so.5
#3  0x00007f6353fd931f in ccnet_main (client=0x1b14120) at mainloop.c:116
#4  0x000000000040e6e7 in main (argc=0, argv=0x7ffff1292dd0) at seaf-daemon.c:534

Thread 3 (Thread 0x7f634e38e700 (LWP 8479)):
#0  0x00007f63528c36f3 in select () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x0000000000432da1 in wt_monitor_job_linux (vmonitor=0x1b43d90) at wt-monitor-linux.c:471
#2  0x00007f6353fda1d9 in job_thread_wrapper (vdata=0x1bbc380, unused=0x0) at job-mgr.c:54
#3  0x00007f635349b218 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x00007f635349a9b5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007f6352b9ce9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#6  0x00007f63528ca38d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#7  0x0000000000000000 in ?? ()

Thread 2 (Thread 0x7f634cf77700 (LWP 19034)):
#0  0x00007f63528be9d3 in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f6352dedee8 in Curl_socket_ready () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#2  0x00007f6352dd9819 in ossl_connect_common () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#3  0x00007f6352ddaf45 in Curl_ossl_connect () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#4  0x00007f6352dee4e9 in Curl_ssl_connect () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#5  0x00007f6352dc5050 in Curl_http_connect () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#6  0x00007f6352dd5efa in Curl_protocol_connect () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#7  0x00007f6352dd61aa in Curl_setup_conn () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#8  0x00007f6352dd6254 in Curl_connect () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#9  0x00007f6352de16d1 in Curl_do_perform () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#10 0x000000000040f818 in http_get (curl=0x7f62f0004600, url=0x7f62e0118570 "https://sync.svc.firenet.ch/seafhttp/repo/644bc872-e486-45a1-93bb-c3b44a9ad57a/commit/HEAD", token=0x1bd55b0 "633990a29ed1556920be6f39f867839fab9193b5", rsp_status=0x7f634cf76ddc, rsp_content=0x7f634cf76d98, 
    rsp_size=0x7f634cf76da0, callback=0, cb_data=0x0, timeout=0) at http-tx-mgr.c:698
#11 0x0000000000410ebc in check_head_commit_thread (vdata=0x1bf4f10) at http-tx-mgr.c:1246
#12 0x00007f6353fda1d9 in job_thread_wrapper (vdata=0x1c740b0, unused=0x0) at job-mgr.c:54
#13 0x00007f635349b218 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x00007f635349a9b5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#15 0x00007f6352b9ce9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#16 0x00007f63528ca38d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#17 0x0000000000000000 in ?? ()

Thread 1 (Thread 0x7f63237fe700 (LWP 19036)):
#0  0x00007f63544f74d6 in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#1  0xeb9eedd8afbe0bd7 in ?? ()
#2  0x983349d9ca62c366 in ?? ()
#3  0x61753907493ed9f6 in ?? ()
#4  0x4394aa569eeacc4d in ?? ()
#5  0xa1eca645e43bb9f8 in ?? ()
#6  0x17ae6e9cca6303f9 in ?? ()
#7  0xd50530c61cbc2373 in ?? ()
#8  0xa4fecc14839492fd in ?? ()
#9  0x00007f635486291a in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#10 0x00007f63100fd920 in ?? ()
#11 0x0000000000000025 in ?? ()
#12 0x00007f63544f3900 in SHA1_Update () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#13 0x00007f6354575e0f in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#14 0x00007f635489e29a in SSL_CTX_new () from /lib/x86_64-linux-gnu/libssl.so.1.0.0
#15 0x00007f6352dd99ee in ossl_connect_common () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#16 0x00007f6352ddaf45 in Curl_ossl_connect () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#17 0x00007f6352dee4e9 in Curl_ssl_connect () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#18 0x00007f6352dc5050 in Curl_http_connect () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#19 0x00007f6352dd5efa in Curl_protocol_connect () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#20 0x00007f6352dd61aa in Curl_setup_conn () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#21 0x00007f6352dd6254 in Curl_connect () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#22 0x00007f6352de16d1 in Curl_do_perform () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#23 0x000000000040f818 in http_get (curl=0x7f632c0010e0, url=0x7f631005dd80 "https://sync.svc.firenet.ch/seafhttp/repo/6e00afaf-3974-4fb9-b88e-91f9cf2772fe/commit/HEAD", token=0x1bc9940 "1b7ba7ba1e011ad398be3ee512d88c5f4221b158", rsp_status=0x7f63237fdddc, rsp_content=0x7f63237fdd98, 
    rsp_size=0x7f63237fdda0, callback=0, cb_data=0x0, timeout=0) at http-tx-mgr.c:698
#24 0x0000000000410ebc in check_head_commit_thread (vdata=0x1bc6640) at http-tx-mgr.c:1246
#25 0x00007f6353fda1d9 in job_thread_wrapper (vdata=0x1b10400, unused=0x0) at job-mgr.c:54
#26 0x00007f635349b218 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#27 0x00007f635349a9b5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#28 0x00007f6352b9ce9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#29 0x00007f63528ca38d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#30 0x0000000000000000 in ?? ()
(gdb) 

[adrianimboden]

I think I had a similar problem with multi-threaded curl usage in an other project.

I'm currently trying out a fix (https://github.com/adrianimboden/seafile/commit/5a3dd241e487c406143fae27771f50f252af5a5e) to see if that solves the problem.

Am I missing something, or is there a considerable code duplication between the ccnet repository and the seafile repository? I made the changes first in the ccnet repository (https://github.com/adrianimboden/ccnet/commit/db3b745a70bd003e9c0f4d765a5120c5bf97ebf7) until I found out that I was changing at the wrong place...

[killing]

@adrianimboden Thank you for debugging this issue. It's very helpful! I think your solution should work. And I believe the same patch has to be applied to WIN32 too?

[adrianimboden]

No Problem, I'm glad to help the project. I'm quite sure that this patch is the solution. I started multiple clients (patched and unpatched), and all of the unpatched ones crashed since yesterday, while the other ones did not crash.

Interestingly, I never saw the problem on windows. Despite that, the locking should do only good, and no harm. I think, the Windows build uses the same libraries (pthread, libcurl with openssl)? If yes, the patch should be applicable without changes for windows.

Are there build instruction for windows?

[killing]

Thank you! Can you make a PR to the 5.0 branch? Sorry we haven't written the instructions for windows. We'll test it ourselves.

[adrianimboden]

Is done. I also created a pull request for the ccnet repository. It looks like there could be the same problem.

[killing]

Thank you for the contribution!