Crashing / closing on 1.1.2?

Support
1

I’m putting this out there before it’s flagged as a bug, but since going to 1.1.2 I have been getting disconnections and when I look, the DOS window has closed and the web page is still open.

So far it’s happened on Server 2016, Windows 10 and Windows 7. Also on Synctrazor. Up until the full release rc2 was fine.

Just wondering if any one else if seeing this.

2

This?

There is no difference between 1.1.2-rc.2 and 1.1.2 though.

3

On a W10 there’s no panic logs. On the server 2016 there is a few and one of the logs shows…

C:/Go/src/internal/poll/fd_windows.go:228 +0x124 internal/poll.(*FD).Read(0xc000b16b00, 0xc0003481c1, 0x1, 0x1, 0x0, 0x0, 0x0) C:/Go/src/internal/poll/fd_windows.go:502 +0x26b net.(*netFD).Read(0xc000b16b00, 0xc0003481c1, 0x1, 0x1, 0x442716, 0xc002f16180, 0x4) C:/Go/src/net/fd_windows.go:152 +0x56 net.(*conn).Read(0xc000ed8020, 0xc0003481c1, 0x1, 0x1, 0x0, 0x0, 0x0) C:/Go/src/net/net.go:177 +0x70 github.com/syncthing/syncthing/lib/tlsutil.(*UnionedConnection).Read(0xc0004061e0, 0xc0003481c1, 0x1, 0x1, 0x4389ed, 0xe30058, 0xc000148780) C:/BuildAgent/work/174e136266f8a219/lib/tlsutil/tlsutil.go:223 +0xc8 net/http.(*connReader).backgroundRead(0xc0003481b0) C:/Go/src/net/http/server.go:677 +0x5f created by net/http.(*connReader).startBackgroundRead C:/Go/src/net/http/server.go:673 +0xd1

only lots more of it. The above is the last entry. The logs finished at 10:27 and I restarted St at 15.22. Not sure if it’s related but can post the full log if it helps.

4

The full panic log would be useful. An excerpt is not, unfortunately.

5

panic-20190508-102727.log (72.7 KB)

I’ve edited out the IDs etc, so hopefully this is all you need

6

Yeah, it’s the linked GitHub issue. Having a folder pointed at a disk root directory with filesystem watching will cause that.

This has been present since 1.1.2-rc.1 which attempted to fix another issue with the same scenario. I just reproduced it. :confused:

7

Would this cause St to crash? seems coincidental that it’s only just started to happen on the new release.

8

Seems the server 2016 St which the above logs refer to closed again, full of the same errors.

Just thinking and looking at the bug that’s been reopened, I use \\?\ on the server to get around long file paths. Could this be responsible?

9

No, it’s not your fault, it’s a bug.

11

I’ve dropped a v1.1.3 release to fix the panic. Filesystem watching of whole disks still won’t work properly though (#5578, same as in v1.1.1).

12

Many thanks for your quick response and hotfix

1 Like
13

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