On Wed, Jul 01, 2020 at 11:43:15AM +0200, R. Diez wrote: > After a 3-month pause, I recently updated my Ubuntu 18.04.4. I am > using a PPA to keep Git more up to date, so I have now "git version > 2.27.0". > > I am now getting this kind of errors: > > fatal: failed to read object cf965547a433493caa80e84d7a2b78b32a26ee35: Interrupted system call > > error: unable to mmap /home/rdiez/[blah blah]/SrcRepo.git/objects/2e/f96ffba4c0d60f36c8779758f82752be380689: Interrupted system call > > I am using a mount point for a network share. Keep in mind that Git thinks > it is working on a local directory, so there should be no sockets or > non-blocking I/O involved. Looking at the code, that message is slightly deceptive. It's reporting a failure from map_loose_object_1(), which calls both open() and mmap(), as well as fstat(). It would be interesting to know which syscall is actually failing. Running the failure case under "strace" would be interesting (likewise to see which signal is causing the interruption). > The problem is probably caused by using SMB to connect to an outdated > Windows server. It has been working for years, but at some point in time it > is bound to fail. The Linux kernel itself seems to introduce bugs in the > SMB/CIFS code every now and then. > > Nevertheless, I am surprised to get such an "Interrupted system call" from > Git. A long time ago I learnt that it is OK for many syscalls to get > interrupted, so you have to loop around them. See here for more information: We do check for signals and re-start read() and write() calls as appropriate. We don't for open(), and nobody has ever complained (though it definitely is documented to result in EINTR, I'd imagine it's relatively rare). I'm not excited about the prospect of adding retry code to every open(), though perhaps doing it with our git_open() wrapper would be sufficient (it's unclear how stdio fopen() behaves). > How can I pin-point this problem? I would like to know where Git is > encountering this error, so that I can troubleshoot it, and maybe report yet > another bug to the Linux SMB/CIFS maintainer. I think the first step is using strace to record the system call returning EINTR (and the signal that interrupted it). I suspect it's in open(), though, and probably not a bug: opening network files may take a while and need to be interruptable. -Peff
