Project

General

Profile

Actions

Bug #3055

closed

sendfile sets *off to 0 when interrupted by SIGALRM

Added by Frank Lahm almost 10 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
High
Assignee:
-
Category:
kernel
Start date:
2012-08-04
Due date:
% Done:

0%

Estimated time:
Difficulty:
Hard
Tags:
needs-triage
Gerrit CR:

Description

After spending several hours investigating a strange problem in Netatalk running on Openindiana I was finally able to track down the problem to sendfile occasionally returning with -1, an errno of EINTR and *off reset to 0.

truss shows:

8.6034  0.0092 sendfilev64(1, 9, 0x08047970, 1, 0x08047964)    Err#4 EINTR
sfv_fd=6 sfv_flag=0x0 sfv_off=644100096 sfv_len=253952
8.6037 0.0003 Received signal #14, SIGALRM [caught]
siginfo: SIGALRM pid=13721 uid=0

sfv_off ist NOT the returned value. In order to get at that I added some debugging code after my sendfile code which showed that *off was 644100096 BEFORE sendfile(), but 0 afterwards:

Apr 15 06:03:06.564213 afpd22475 {dsi_stream.c:354} (E:DSI): sendfile: EINTR - old offset: 644100096, new offset: 0
Apr 15 06:03:15.043380 afpd22475 {dsi_stream.c:354} (E:DSI): sendfile: EINTR - old offset: 821833728, new offset: 0
Apr 15 06:03:54.438215 afpd22475 {dsi_stream.c:354} (E:DSI): sendfile: EINTR - old offset: 278147072, new offset: 0
Apr 15 06:04:01.431494 afpd22475 {dsi_stream.c:354} (E:DSI): sendfile: EINTR - old offset: 501493760, new offset: 0

Clearly, if sendfile() is returning with sth like EAGAIN or EINTR *off must still contain the current offset, possibly update by the amount of bytes sent.

Workaround:
in case of sendfile returning -1 with an errno of EINTR, check whether *off is 0 and reasign *off appropiately. I'm assuming 0 bytes have been sent in this case.


Files

truss.txt.zip (170 KB) truss.txt.zip Frank Lahm, 2012-08-04 01:25 PM
Actions

Also available in: Atom PDF