Project

General

Profile

Feature #2883

fdevent_init should check if SOCK_NONBLOCK works

Added by staples1347 4 months ago. Updated 3 days ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
Category:
core
Target version:
Start date:
2018-04-10
Due date:
% Done:

100%

Estimated time:
Missing in 1.5.x:

Description

In src/fdevent.c, fdevent_init only checks if SOCK_CLOEXEC works, but doesn't check if SOCK_NONBLOCK works as well. It also doesn't use fcntl to double-check that the SOCK_CLOEXEC flag has been applied.

I have an Android Acer Iconia A500 running a custom rom with kernel: 3.8.13.28-digetx-thor-t72-android and for some reason SOCK_NONBLOCK is ignored when passed to socket but an error isn't returned. This occurs even when I compile with NDK API: 21 where SOCK_NONBLOCK is supported instead of NDK API: 14. The attached test program: testsocketnonblock.c displays 1 for Cloexec but 2 for Nonblock (2 means an error wasn't returned from the call to socket, but the fcntl test returned that the flag wasn't set). On my laptop with Linux Gentoo kernel: 4.14.32-gentoo, both tests return 1. Without a workaround, this causes lighttpd to freeze when running on my tablet when multiple html files are requested by a client browser.

testsocketnonblock.c (787 Bytes) testsocketnonblock.c staples1347, 2018-04-10 07:40

Associated revisions

Revision 78024584 (diff)
Added by gstrauss 10 days ago

[core] check if SOCK_NONBLOCK is ignored (fixes #2883)

x-ref:
"fdevent_init should check if SOCK_NONBLOCK works"
https://redmine.lighttpd.net/issues/2883

History

#1

Updated by gstrauss 4 months ago

  • Tracker changed from Bug to Feature
  • Target version changed from 1.4.50 to 1.4.x

for some reason SOCK_NONBLOCK is ignored when passed to socket but an error isn't returned.

That's pretty ridiculous and arguably a bug in that version of Android or the custom ROM 3.8.13.28-digetx-thor-t72-android

SOCK_CLOEXEC and SOCK_NONBLOCK were added in the later part of the 2.6 kernel series. There are comments in fdevent.c which refer to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=529929 and note that SOCK_CLOEXEC might not work in kernels prior to 2.6.27.

I'll look into adding some checks in lighttpd, but don't like the idea of lighttpd having to validate many different types of operating system behavior at startup. Have you filed a bug for that version of Android? lighttpd is probably not the only application affected by this.

#2

Updated by staples1347 4 months ago

Yes it is ridiculous and I already figured it is a bug on the tablet as the kernel version is high enough to support SOCK_NONBLOCK, but this tablet and others like it might not be getting any more system updates (I mainly use it to make sure our project still works with old Android devices). I haven't yet posted a bug report to Android I am going to check if Google's Android Emulators also have the bug first, the reason why I only just noticed this issue is I've been updating the build system that we use for the project that the company I work for is working on and the previous Android NDK we were using didn't define SOCK_CLOEXEC or SOCK_NONBLOCK when targeting older Android versions.

My main reason for filing the bug in lighttpd though was that other Android or even non-Android or non-Linux systems may be affected where a user compiles the latest lighttpd on a dev system that defines SOCK_NONBLOCK, but the system they deploy to has this issue but for whatever reason they are unable to update their operating system/libraries, and since lighttpd already had some checks for SOCK_CLOEXEC it seemed like adding additonal checks as per the test program would be fairly straight forward.

#3

Updated by gstrauss 4 months ago

where a user compiles the latest lighttpd on a dev system that defines SOCK_NONBLOCK, but the system they deploy to has this issue

It is often unwise to compile and build on a system with libraries newer than the target systems to which it will be deployed. If your cross-compilation environment provides the definitions for SOCK_NONBLOCK, then it is reasonable to assume that the target system will be running kernels that support SOCK_NONBLOCK or that the system libraries will properly return an error, e.g EINVAL for the unsupported flag.

.

I have posted a preliminary patch to my personal/gstrauss/master branch. See DevelGit

#4

Updated by staples1347 4 months ago

It looks like that patch has fixed the problem on my tablet. Thanks. I have also tested various Android versions with Android Emulator and they don't appear to have the problem.

#5

Updated by gstrauss 4 months ago

  • Status changed from New to Patch Pending
  • Target version changed from 1.4.x to 1.4.50
#6

Updated by gstrauss 3 days ago

  • Status changed from Patch Pending to Fixed
  • % Done changed from 0 to 100

Also available in: Atom