View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003926 | libmicrohttpd | internal event loop | public | 2015-07-31 15:53 | 2021-09-02 15:54 |
| Reporter | davidgf | Assigned To | Christian Grothoff | Due Date | |
| Priority | high | Severity | crash | Reproducibility | random |
| Status | closed | Resolution | fixed | ||
| Platform | Linux 3.X | OS | Linux | OS Version | 3.X |
| Product Version | Git master | ||||
| Target Version | 0.9.43 | Fixed in Version | 0.9.43 | ||
| Summary | 0003926: Checking result of close() in a wrong way? | ||||
| Description | It seems that daemon.c checks whether the result from close() is zero. In case it's non zero it may trigger a panic. POSIX says that we can get EINTR, therefore IMHO we should not check close() result, just makes no sense. | ||||
| Steps To Reproduce | Under heavy load, multithreaded program I get random crashes at "panic close failed". | ||||
| Tags | No tags attached. | ||||
| Well, POSIX is (or at least used-to-be) *wrong* on close in the first place. Terrible choice of semantics. (See also http://lwn.net/Articles/576478/). Now, it seems (!) from this article that it may be safe to continue on GNU/Linux if errno is EINTR or (more correct) EINPROGRESS, but unsafe on other "POSIX" platforms (possible leak of a file-descriptor). Now, this is a kernel/libc issue, as libc should probably just return 0 instead of EINPROGRESS (see also https://news.ycombinator.com/item?id=3363819). So on GNU/Linux, where the FD is *always* closed, POSIX says that errno should be EINPROGRESS (or the return value just zero). musl now does this (http://ewontfix.com/4/), so we get additional fun with the "correct" action depending on the kernel and the libc. Party. | |
| So in non-linux platforms, what happens if we get EINTR/EINPROGRESS? Should we re-issue the syscall? Cause that would be very tricky | |
| My reading is that only HP-UNIX has the non-closing semantics, and in that case may have undefined semantics (as in, it may be closed -- or not). So I'm going with screw HP-UNIX, never retry, ignore all errors except EBADF. | |
| Fix committed as SVN 36164. | |
| Fix committed to master branch. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-07-31 15:53 | davidgf | New Issue | |
| 2015-08-02 16:49 | Christian Grothoff | Note Added: 0009512 | |
| 2015-08-02 16:49 | Christian Grothoff | Note Edited: 0009512 | |
| 2015-08-02 16:58 | davidgf | Note Added: 0009513 | |
| 2015-08-02 17:11 | Christian Grothoff | Note Added: 0009514 | |
| 2015-08-02 17:11 | Christian Grothoff | Note Added: 0009515 | |
| 2015-08-02 17:12 | Christian Grothoff | Status | new => resolved |
| 2015-08-02 17:12 | Christian Grothoff | Fixed in Version | => 0.9.43 |
| 2015-08-02 17:12 | Christian Grothoff | Resolution | open => fixed |
| 2015-08-02 17:12 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2015-08-02 17:12 | Christian Grothoff | Product Version | => Git master |
| 2015-08-02 17:12 | Christian Grothoff | Target Version | => 0.9.43 |
| 2015-09-16 09:00 | Christian Grothoff | Status | resolved => closed |
| 2021-09-02 15:54 | Christian Grothoff | ||
| 2021-09-02 15:54 | Christian Grothoff | Note Added: 0018193 | |
| 2024-01-21 12:24 | Christian Grothoff | Category | libmicrohttpd internal select => internal event loop |