os: Lstat() returns error "Interrupted system call"

[calmh]

go1.3.1 linux-arm

This one is a bit tricky; I don't have a reproducer, because it's reported by a user of
my program that runs it on hardware/OS I don't have (Android on a Nexus 4, specifically).

The os.Lstat() call in
https://github.com/syncthing/syncthing/blob/v0.9.4/scanner/walk.go#L242
"sometimes" returns the error "Interrupted system call". There
doesn't seem to be any particular pattern to it; the program is something that runs in
the background and repeatedly does the scanning in question, and it'll fail "after
a while".

I haven't seen this myself or received any reports of it on non-Android non-ARM systems,
for whatever that's worth.

Sorry for the extreme vagueness. :(

[gopherbot]

Comment 1 by firecat4153:

Also have this same error on a Verizon Motorola MAXX (Android 4.4.4 kernel
3.4.42-gb33f23d)

[bradfitz]

Comment 2:

I guess we should audit all uses of system calls to check if they need EINTR loops.

Labels changed: added release-go1.4, repo-main.

Status changed to Accepted.

[rsc]

Comment 3:

I am not putting EINTR loops around everything "just because". That's cargo cult
programming. We register all the async signal handlers to restart the system call for us.
What is interrupting the Lstat? That would be the first thing to find out. strace might
tell us.

Status changed to WaitingForReply.

[bradfitz]

Comment 4:

From which signal does (*os.File).write's EINTR come? It lacks a comment but retries on
EINTR.
I see SIGPIPE might be SA_RESTART. Not sure why, though.
I'll try to reproduce this on a program repeatedly flushing its buffer+dentry cache and
doing I/O and doing Lstats with another child barraging it with signals. I kinda doubt
this is ARM-specific, but I bet ARM devices are just slower enough to make triggering it
easier? No clue.

[calmh]

Comment 5:

I could possibly see it being Android specific though, since there's a FUSE
layer doing some funny business between the program and the actual file
system?

[davecheney]

Comment 6:

This is probably unrelated, but possible there is a problem with EINTR handling on
some/all arm platforms. Looking at Russ' comment in #3,
davecheney/gpio#12, should not be possible.

[ianlancetaylor]

Comment 7:

Re: comment #4: all signals are marked SA_RESTART at all times.

[rsc]

Comment 8:

If FUSE is the one being interrupted and returning EINTR, then us returning EINTR is
probably the right answer. I really don't think this is Go's fault. If someone has
details to the contrary, then please open a new issue.

Status changed to WorkingAsIntended.