Fatal error: objectstart: bad pointer in unexpected span

panic log : http://0da65ae210b43278.paste.se/

The index folder had grown out of control, gobbling up, >22k index files, 30Gb of diskspace (all free space).

help?

You are not using an official build. We can’t support an unofficial build, as we can’t say what has been changed in the build.

okay… beats me how an unofficial built could end up on that system. In any case, I’ve redownloaded from https://github.com/syncthing/syncthing/releases/download/v0.12.9/syncthing-windows-amd64-v0.12.9.zip and it’s re-indexing.

To be continued…

well, during the re-indexing the same thing happened. The index grew so large (20k files, over 30Gb) that it filled the OS drive. This is the LOG file from index-folder : https://drive.google.com/file/d/0BwCQHV7z4Tg4M0lPVURkXzhud0E/view?usp=sharing

Help?

This is the database log, so it’s not very useful. Same thing being same panic? Also, how much data are you indexing (in terms of total size and total file+dir count)?

This host is acting as a mirror for another one. The other host has an index of 5.6GB containing 2633 index-files.

The figures for data files are (approx.) 17079 items, 4453GiB. As per Syncthing’s webif.

The database log is the only one I could grab, a full OS drive doesn’t leave much space for other logs. A panic log wasn’t present.

Edit : what would be the easiest way to make ST write its log(s) to another drive ?

Edit 2: that would be syncthing.exe -logfile D:\syncthing.log , should I enable any variables to help troubleshooting ?

Well, running out of space is probably the issue, not the build.

What you can try and do is restart it multiple times along the way, which should trigger index compaction upon restarting.

We’ve had similar reports where the index compaction just doesn’t happen because the runtime is busy spending most of it’s time hashing.

will try.

Question : when you say “compacting”, to me that means reducing the filesize of the index files. Does it also mean the number of indexfiles get reduced?

I’m asking bc one host ends up filled with 20k index files, while the other has just 2k.

Both, size and number of files. It should drop down immediately after restarting though.

Issue remains unresolved :frowning: I do have some extra info on what is exactly happening.

Rebuilding the index completes fine, when the remote host is offline (ST not running). When both hosts come online, they exchange indexes, and the index folder just keeps growing untill C: is full (C = 64GB SSD).

I have moved the home folder onto another HDD (D = 2TB ), to see if ST would fill that also…

That’s a different problem than the original though. @calmh was doing some research into this, but I don’t think we have an answer.

re the OP, i saw a panic log, and assumed it was related to this free-space munching issue. I guess it was an unrelated fluke, as you say.

So, the index-size thing is on @calmh 's plate?

Well, I know he was looking into it, but I think its hasn’t been looked at for a while.

It’s really on the database packages plate, but yeah it seems like it sometimes does not compact for a while. To confirm that, does the database shrink when syncthing restarts?

correct, but the issue seems to happen only when a host is connected to a remote host.

Migrating the home directory to a larger disk has solved the symptoms for me.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.