Seadrive linux daemon segfaults after file upload

I’m trying to use SeaDrive client and it appears to crash after attempting to upload files. Log before crash:

[03/22/20 11:50:11] seadrive.c(697): Starting SeaDrive client 1.0.9
[03/22/20 11:50:11] repo-mgr.c(2583): switching account to https://[MY_SERVER] [MYACC].
[03/22/20 11:50:11] socket file exists, delete it anyway
[03/22/20 11:50:11] seadrive.c(725): rpc server started.
[03/22/20 11:50:13] sync-mgr.c(1457): All repo fs trees are loaded.
[03/22/20 11:50:13] sync-mgr.c(586): Repo 'DND' sync state transition from 'synchronized' to 'committing'.
[03/22/20 11:50:13] sync-mgr.c(2727): All operations of repo DND(42987d48) have been processed.
[03/22/20 11:50:13] sync-mgr.c(586): Repo 'My Library' sync state transition from 'synchronized' to 'uploading'.
[03/22/20 11:50:13] sync-mgr.c(586): Repo 'DND' sync state transition from 'committing' to 'synchronized'.
[03/22/20 11:50:13] http-tx-mgr.c(4057): Upload with HTTP sync protocol version 2.
[03/22/20 11:50:13] http-tx-mgr.c(1276): Transfer repo '810788c0': ('normal', 'init') --> ('normal', 'check')
[03/22/20 11:50:13] http-tx-mgr.c(1276): Transfer repo '810788c0': ('normal', 'check') --> ('normal', 'commit')
[03/22/20 11:50:13] http-tx-mgr.c(1276): Transfer repo '810788c0': ('normal', 'commit') --> ('normal', 'fs')
[03/22/20 11:50:13] http-tx-mgr.c(1276): Transfer repo '810788c0': ('normal', 'fs') --> ('normal', 'data')

Here is the backtrace I managed to get out:

0x00007ffff758f705 in realloc () from /usr/lib/
(gdb) backtrace
#0  0x00007ffff758f705 in realloc () at /usr/lib/
#1  0x00007ffff7762b29 in g_realloc () at /usr/lib/
#2  0x0000000000408890 in recv_response (contents=0x7fffb0002be5, size=<optimized out>, nmemb=<optimized out>, userp=0x7fffd57f9ae0) at http-tx-mgr.c:605
#3  0x00007ffff7f1b110 in  () at /usr/lib/
#4  0x00007ffff7f2d6e4 in  () at /usr/lib/
#5  0x00007ffff7f37305 in  () at /usr/lib/
#6  0x00007ffff7f38781 in curl_multi_perform () at /usr/lib/
#7  0x00007ffff7f2eacc in curl_easy_perform () at /usr/lib/
#8  0x0000000000409243 in http_put
    (curl=0x7fffb0001380, url=0x7fffb00df8d0 "https://[MY_SERVER]/seafhttp/repo/810788c0-5f28-4e6f-b336-a6d0d47281d6/block/23ecd35ac9cbce176a61b1cd215b462d0d64366b", token=0x7fffb00dd540 "\200\324\006\260\377\177", req_content=0x0, req_size=4258835, callback=0x0, cb_data=0x7fffd57f9de0, rsp_status=0x0, pcurl_error=0x7fffd57f9dc4, timeout=<optimized out>, rsp_size=<optimized out>, rsp_content=<optimized out>) at http-tx-mgr.c:909
#9  0x000000000040e602 in send_block
    (conn=<optimized out>, conn=<optimized out>, progress=<optimized out>, size=<optimized out>, block_id=<optimized out>, task=<optimized out>)
    at http-tx-mgr.c:3555
#10 upload_file (block_list=<optimized out>, file_size=<optimized out>, file_path=<optimized out>, conn=<optimized out>, http_task=<optimized out>)
    at http-tx-mgr.c:3728
#11 upload_file_thread_func (data=0x1, user_data=0x7fffe0020500) at http-tx-mgr.c:3807
#12 0x00007ffff773f4e7 in  () at /usr/lib/
#13 0x00007ffff7741e71 in  () at /usr/lib/
#14 0x00007ffff76d346f in start_thread () at /usr/lib/
#15 0x00007ffff76033d3 in clone () at /usr/lib/

One thing to note is that used libcurl is actually libcurl-compat 4.6.0 from arch repo (since older 4.5.0 version is not available anymore).

Any idea what could be wrong?

This is on Manjaro Linux.

I have the same exact issue, same backtrace and logs and everything. Did you ever resolve this?

The server is a completely fresh installation, and it’s happening on two separate clients with Arch Linux, both with the most recent versions of seadrive-fuse and libsearpc.

Also, the error doesn’t happen when I bypass the nginx reverse proxy (which is there for SSL termination) and correct directly to the HTTP endpoint from the seafile docker container. My nginx config is below:

server {
	listen 443 ssl http2;

	ssl_certificate /etc/letsencrypt/live/;
	ssl_certificate_key /etc/letsencrypt/live/;

	location / {
		proxy_set_header Host $host;
		proxy_set_header X-Real-IP $remote_addr;
		# the seafile server ip is different from this reverse proxy ip
		proxy_pass http://<seafile server ip>:7070;

This issue has been plaguing me for months, but of course the second I post about it I find the solution. I just had to add client_max_body_size 0; to the nginx reverse proxy. The hours I spent on this when I could have just looked at nginx logs and realized the problem…

In my defense, seadrive really shouldn’t be segfaulting in this case.

1 Like

This is a bug and will be fixed in Linux 2.0.29 version.

1 Like