chrisvdb

[Solved] Assert Failed /mnt/jenkins/workspace/build-Sync-X64/readonlystrategy.cpp:509

Recommended Posts

Hi,

 

I'm using btsync 2.1.3 on Ubuntu. I'm trying to sync ~200 GB of pictures between two machines using a 1.4 style folder. One peer has a rw secret whereas the other one has a encrypted ro secret.

 

The latter gets the following error after ~20 GB of sync'ing:

 

[20150817 06:58:49.872] SyncFolderScanner: Posting update event for file "/var/btsync/chrisvdb/Pictures/5L6JR35WLCIKX373LNF6BJ5NVQIIZRDXZPA4AMI/KXHIPLDBK7JHMIPXR6RFF2NQ44/APUKYQ
PDDMUCU3S4BE6FF3IKYA/WFKIWNVLIRSSSQYGM3ZGQZ3OY4"
[20150817 06:58:49.872] FC[27CC]: file updated - processing file /var/btsync/chrisvdb/Pictures/5L6JR35WLCIKX373LNF6BJ5NVQIIZRDXZPA4AMI/KXHIPLDBK7JHMIPXR6RFF2NQ44/APUKYQPDDMUCU3S
4BE6FF3IKYA/WFKIWNVLIRSSSQYGM3ZGQZ3OY4 t:1218875410 s:4206152 id:2305:149695474
[20150817 06:58:49.872] JOURNAL[27CC]: detected updated file "5L6JR35WLCIKX373LNF6BJ5NVQIIZRDXZPA4AMI/KXHIPLDBK7JHMIPXR6RFF2NQ44/APUKYQPDDMUCU3S4BE6FF3IKYA/WFKIWNVLIRSSSQYGM3ZGQ
Z3OY4". Checking filehash
[20150817 06:58:49.872] assert failed /mnt/jenkins/workspace/Build-Sync-x64/ReadOnlyStrategy.cpp:509

 
Deleting the file will restart the sync'ing temporarily but the same issue occurs again after a few hours.
 
Please find the logs of the encrypted read-only peer here: https://www.dropbox.com/s/2uj8xlstcff70aq/sync.log.tgz?dl=0
 
Regards,
Chris.

Share this post


Link to post
Share on other sites

Chris,

 

That assert means that option "Overwrite changed files' got disabled for encrypted RO share. Did you disable it - in UI or in config? 

Share this post


Link to post
Share on other sites

Hi,

 

I haven't disabled this in the configuration.

 

Wouldn't the assert mean that the file is altered although it is not supposed to be altered in ro mode? I have checked and there is no other process accessing the files.

 

I just happened again... I have uploaded the logs again: https://www.dropbox.com/s/y6arxoub5b8bcyk/sync.log.tar.bz2?dl=0 . Removing the file again (temporarily) solved the issue.

 

Chris.

Share this post


Link to post
Share on other sites

Chris, 

 

 

Wouldn't the assert mean that the file is altered although it is not supposed to be altered in ro mode? 

no. That assert line in log means that option "Overwrite" gets disabled. Do you run nSync with UI? Can you please make screenshot of folder preferences?

Technically files can be changed in RO mode. but in encrypted RO folder such files shall always equal to files on RW peers, thus such files re-sycned  immediately after change, due to "Overwrite" option enabled. 

 

What is exactly the problem with it is apart from you seeing this line in the log?

Share this post


Link to post
Share on other sites

No, I run sync in configuration mode with the webgui disabled. Configuration:

{  "device_name": "Timbuktu", "listening_port" : 65432, "storage_path" : "/var/lib/btsync", "check_for_updates" : false, "use_upnp" : false, "download_limit" : 0, "upload_limit" : 0, "webui" : {   //"listen" : "0.0.0.0:8888",   //"login" : "admin",   //"password" : "password" } , "shared_folders" : [   {// Pictures (encrypted read-only)      "secret" : "<snip>",     "dir" : "/var/btsync/chrisvdb/Pictures",     "use_relay_server" : false,     "use_tracker" : true,     "use_dht" : false,     "search_lan" : false,     "use_sync_trash" : true,     "known_hosts" :     [ "<snip>:65432" ]   }]  , "disk_low_priority" : false, "lan_encrypt_data" : true, "lan_use_tcp" : true, "folder_rescan_interval" : 3600, "rate_limit_local_peers" : false, "sync_trash_ttl" : 30, "log_size" : 100}

After the error btsync crashes. I need to delete the affected file and restart btsync for it to continue (until the next time).

Share this post


Link to post
Share on other sites

chrisvdb,

 

Tried to reproduce - didn't crash. Can you please collect the logs from both peers and cash dumps from this Ubuntu: in terminal  run ulimit -c unlimited.  From this Terminal window start Sync. When Sync crashes, there should be a crash dump placed near btsync binary. Submit all via web form to support team. 

Please do not forget to put the link to this topic. and please, and please tell a few words about Faraday (what is it) and the file in problem - is a a regular jpg? 

 

Thank you!

 

So far you can user lsof or fatrace for ubuntu to check what might be accessing the file.

Share this post


Link to post
Share on other sites

Hi Helen,

 

I have restarted btsync on Timbuktu (Linux timbuktu 3.19.0-20-generic #20-Ubuntu SMP Fri May 29 10:10:47 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux) with 'ulimit -c unlimited'. I will post the log + coredump on the next failure.

 

Faraday is a QNAP TS-253 NAS running the same version of btsync. I use the standard (outdated) QNAP btsync package but replaced the binary with the newer version (32-bit glib 2.3). Btsync on Faraday hasn't crashed a single time yet.

 

Do you know how to enable debug logging on btsync for QNAP? I tried putting debug.txt in the directory of the binary but that didn't seem to have worked.

 

The files are mostly normal JPGs and some AVIs. I do not know what files are the culprits due to the encryption... I can only see the encrypted filename on Timbuktu.

 

Cheers,
Chris.

Share this post


Link to post
Share on other sites

Chris,

 

Success - I was finally able to reproduce it! I required me to manually change files on RO and RW peers though, but the pattern seems to be the same. So no need for logs and dumps so far, I guess, I've collected these from my machines. But perhaps we might need some additional info from you, so I'll write to you then. 

Thank you for the report!

Share this post


Link to post
Share on other sites

Ok, so, btsync ran for a few hours without issues and then crashed again. Unlike the previous crashes removing the faulty file does not seem to fix the issue... when I restart btsync it crashes again a few seconds later on a different file.

 

I have coredumps and logs in case you still want them.

Share this post


Link to post
Share on other sites

Hello,

 

yes, please send them to us. via the web form.  Hope they are not too big to attach?

Thank you! mention the topic forum and add that this is for Helen. Thank you. 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.