Bug #2925

sendfile reports success but no data sent in special case

Added by tautolog over 1 year ago. Updated over 1 year ago.

Target version:
Start date:
Due date:
% Done:



When I send a small header with send() first, and then send a particular file with sendfile(), sendfile() will report success of all data sent, but not send any data to the socket, seemingly related to send length. I have created a minimal test case which reproduces the issue on my system.

I compile sendfile_case.c with:
$ cc -o sendfile_case sendfile_case.c

In another terminal, I run:
$ netcat -l -p 8089 > feed.log

In the first terminal, I run:
# ./sendfile_case
sbytes = 16275

It exits fine, showing the whole file contents being sent, but netcat will be hung, and only will have printed the header.

This code works fine on Linux and OS X (in my application, with IFDEFs for different sendfile argument semantics, of course). The minimal case only does the DragonFly sendfile() call (and probably FreeBSD). I actually bisected it to find the failure threshold:
16275 failed
16274 failed
4096 failed
2048 failed
1836 failed
1811 failed
1806 failed
1801 failed
1796 failed
1793 failed
1792 failed (multiple times)
1791 succeeded (multiple times)
1786 succeeded
1736 succeeded
1636 succeeded
1536 succeeded
1024 succeeded
100 succeeded

1791 sendfile bytes succeeds, and 1792 sendfile bytes fails. The previously sent header is 79 bytes, so 1870 total bytes succeeds, and 1871 total bytes failed.

The version I am running is about 2 months old. I searched for changes to the system call since then, and searched here, and didn't see anything related.

$ uname -a
DragonFly 4.5-DEVELOPMENT DragonFly v4.5.0.954.g7ef02-DEVELOPMENT #6: Sun May 15 22:43:20 PDT 2016 :/usr/obj/usr/src/sys/X86_64_GENERIC x86_64 - data file to send (15.9 KB) tautolog, 07/17/2016 09:47 PM

sendfile_case.c View - minimal test case (1.26 KB) tautolog, 07/17/2016 09:56 PM

dump.bin - tcpdump -ni lo0 -w dump.bin (74.9 KB) tautolog, 07/17/2016 11:07 PM

pf.conf View - firewall config (1.29 KB) tautolog, 07/17/2016 11:16 PM


#1 Updated by tautolog over 1 year ago

#2 Updated by tautolog over 1 year ago

#3 Updated by tautolog over 1 year ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100

Turns out my pf referenced "lo" instead of "lo0" for loopback device. The problem was a lack of acks. Thanks to sephe for the help figuring this out. :)

Also available in: Atom PDF