| Summary: | [GTK] WebKitGtk+ uses too many file descriptors | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Andres Gomez Garcia <agomez> | ||||||||||||||||||||||
| Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> | ||||||||||||||||||||||
| Status: | RESOLVED FIXED | ||||||||||||||||||||||||
| Severity: | Critical | CC: | benjamin, bugs-noreply, bugzilla, cdumez, cgarcia, clopez, cmarcelo, commit-queue, lantw44, mcatanzaro, nekohayo, svillar | ||||||||||||||||||||||
| Priority: | P2 | ||||||||||||||||||||||||
| Version: | WebKit Local Build | ||||||||||||||||||||||||
| Hardware: | Unspecified | ||||||||||||||||||||||||
| OS: | Linux | ||||||||||||||||||||||||
| See Also: |
https://bugzilla.gnome.org/show_bug.cgi?id=728352 https://bugzilla.gnome.org/show_bug.cgi?id=762030 |
||||||||||||||||||||||||
| Bug Depends on: | 154852 | ||||||||||||||||||||||||
| Bug Blocks: | |||||||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||||||
|
Description
Andres Gomez Garcia
2015-12-15 15:30:29 PST
(In reply to comment #0) ... > Epiphany 3.18.0 and WebKit 2.10.3 It probably applies to 2.10.3 but, in this case, I was using 2.10.4 (In reply to comment #1) > (In reply to comment #0) > ... > > Epiphany 3.18.0 and WebKit 2.10.3 > > It probably applies to 2.10.3 but, in this case, I was using 2.10.4 Also with 2.10.5 *** Bug 150899 has been marked as a duplicate of this bug. *** (In reply to comment #3) > *** Bug 150899 has been marked as a duplicate of this bug. *** This bug is worrisome. In my opinion, the importance should rise to CRITICAL. I agree, it sounds really bad. Though for some reason, I've never seen this bug myself.... *** Bug 154446 has been marked as a duplicate of this bug. *** FTR, in my box: $ ulimit -a core file size (blocks, -c) unlimited data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 31341 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 31341 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited Next time it happens I will check that the WebProcess is not getting a different limit value than my shell. I will check the limits of the $pid giving the problem: $ cat /proc/$pid/limits Also, I will check the number of open files with something like: $ ls -l /proc/$pid/fd|wc -l" Created attachment 271999 [details]
WebProcess BT from gdb
Happened again.
This time is again interrelated with a SIGSEV in GStreamer.
Created attachment 272000 [details]
Epiphany BT from gdb
Created attachment 272001 [details]
Small patch to increase the messageMaxSize to 8192 at ConnectionUnix.cpp
This BTs happened after applying this small patch.
This was in epiphany's output: (WebKitWebProcess:23566): GStreamer-CRITICAL **: Trying to dispose element appsrc13, but it is in READY instead of the NULL state. You need to explicitly set elements to the NULL state before dropping the final reference, to allow them to clean up. This problem may also be caused by a refcounting bug in the application or some element. (WebKitWebProcess:23566): GStreamer-CRITICAL **: Trying to dispose element webkitwebsrc0, but it is in READY instead of the NULL state. You need to explicitly set elements to the NULL state before dropping the final reference, to allow them to clean up. This problem may also be caused by a refcounting bug in the application or some element. [New Thread 0x7fffdd430700 (LWP 21431)] (WebKitWebProcess:23566): GStreamer-CRITICAL **: gst_uri_handler_get_uri: assertion 'GST_IS_URI_HANDLER (handler)' failed (WebKitWebProcess:23566): GStreamer-CRITICAL **: gst_uri_get_protocol: assertion 'uri != NULL' failed $ cat /proc/23566/limits Limit Soft Limit Hard Limit Units Max cpu time unlimited unlimited seconds Max file size unlimited unlimited bytes Max data size unlimited unlimited bytes Max stack size 8388608 unlimited bytes Max core file size unlimited unlimited bytes Max resident set unlimited unlimited bytes Max processes 31341 31341 processes Max open files 1024 4096 files Max locked memory 65536 65536 bytes Max address space unlimited unlimited bytes Max file locks unlimited unlimited locks Max pending signals 31341 31341 signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0 Max realtime timeout unlimited unlimited us $ ls -l /proc/23566/fd|wc -l 943 $ ps aux | grep epi ... tanty 23249 0.2 2.1 3504316 170052 pts/22 Sl+ Feb22 3:22 /opt/gnome-os/tanty/epiphany/install/bin/epiphany tanty 23566 3.8 15.0 5486016 1216208 pts/22 tl+ Feb22 45:25 /opt/gnome-os/tanty/epiphany/install/libexec/webkit2gtk-4.0/WebKitWebProcess 21 tanty 24107 0.2 0.7 22999288 63596 pts/22 tLl+ Feb22 2:45 /opt/gnome-os/tanty/epiphany/install/libexec/webkit2gtk-4.0/WebKitNetworkProcess 12 $ ls -l /proc/23249/fd|wc -l 33 $ cat /proc/23249/limits Limit Soft Limit Hard Limit Units Max cpu time unlimited unlimited seconds Max file size unlimited unlimited bytes Max data size unlimited unlimited bytes Max stack size 8388608 unlimited bytes Max core file size unlimited unlimited bytes Max resident set unlimited unlimited bytes Max processes 31341 31341 processes Max open files 1024 4096 files Max locked memory 65536 65536 bytes Max address space unlimited unlimited bytes Max file locks unlimited unlimited locks Max pending signals 31341 31341 signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0 Max realtime timeout unlimited unlimited us $ ls -l /proc/23566/fd|wc -l 943 $ cat /proc/23566/limits Limit Soft Limit Hard Limit Units Max cpu time unlimited unlimited seconds Max file size unlimited unlimited bytes Max data size unlimited unlimited bytes Max stack size 8388608 unlimited bytes Max core file size unlimited unlimited bytes Max resident set unlimited unlimited bytes Max processes 31341 31341 processes Max open files 1024 4096 files Max locked memory 65536 65536 bytes Max address space unlimited unlimited bytes Max file locks unlimited unlimited locks Max pending signals 31341 31341 signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0 Max realtime timeout unlimited unlimited us It happened again so it is clear that the small patch to increase the messageMaxSize is not really helping. I will revert it. Also, the one thing I'm clearly noticing is that this problem usually happens to me during the first hours of the morning, after having an Epiphany instance opened through the whole night. I wonder if we are leaking fds ... --- $ ps aux | grep epiph tanty 13591 0.0 0.6 1740252 55916 pts/22 Sl+ 13:05 0:00 /opt/gnome-os/tanty/epiphany/install/libexec/webkit2gtk-4.0/WebKitDatabaseProcess 34 ... tanty 23363 0.5 3.6 3589988 290940 pts/22 Sl+ Feb23 7:44 /opt/gnome-os/tanty/epiphany/install/bin/epiphany tanty 23531 0.2 1.4 67305668 114536 pts/22 SLl+ Feb23 4:01 /opt/gnome-os/tanty/epiphany/install/libexec/webkit2gtk-4.0/WebKitNetworkProcess 11 tanty 23543 3.9 19.6 6453720 1583652 pts/22 tl+ Feb23 59:48 /opt/gnome-os/tanty/epiphany/install/libexec/webkit2gtk-4.0/WebKitWebProcess 20 $ for i in 23363 23531 23543; do ls -l /proc/$i/fd|wc -l; cat /proc/$i/limits; done 37 Limit Soft Limit Hard Limit Units Max cpu time unlimited unlimited seconds Max file size unlimited unlimited bytes Max data size unlimited unlimited bytes Max stack size 8388608 unlimited bytes Max core file size unlimited unlimited bytes Max resident set unlimited unlimited bytes Max processes 31341 31341 processes Max open files 1024 4096 files Max locked memory 65536 65536 bytes Max address space unlimited unlimited bytes Max file locks unlimited unlimited locks Max pending signals 31341 31341 signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0 Max realtime timeout unlimited unlimited us 25 Limit Soft Limit Hard Limit Units Max cpu time unlimited unlimited seconds Max file size unlimited unlimited bytes Max data size unlimited unlimited bytes Max stack size 8388608 unlimited bytes Max core file size unlimited unlimited bytes Max resident set unlimited unlimited bytes Max processes 31341 31341 processes Max open files 1024 4096 files Max locked memory 65536 65536 bytes Max address space unlimited unlimited bytes Max file locks unlimited unlimited locks Max pending signals 31341 31341 signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0 Max realtime timeout unlimited unlimited us 1025 Limit Soft Limit Hard Limit Units Max cpu time unlimited unlimited seconds Max file size unlimited unlimited bytes Max data size unlimited unlimited bytes Max stack size 8388608 unlimited bytes Max core file size unlimited unlimited bytes Max resident set unlimited unlimited bytes Max processes 31341 31341 processes Max open files 1024 4096 files Max locked memory 65536 65536 bytes Max address space unlimited unlimited bytes Max file locks unlimited unlimited locks Max pending signals 31341 31341 signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0 Max realtime timeout unlimited unlimited us Created attachment 272109 [details]
Epiphany BT from gdb, for the latest case.
Created attachment 272110 [details]
WebProcess BT from gdb, for the latest case.
Created attachment 272491 [details]
List of the 1005 open fds for the WebProcess
This time, Epiphany got stalled spitting this kind of messages like crazy:
(WebKitWebProcess:8630): GStreamer-WARNING **: gstsystemclock: write control failed in wakeup_async, trying again: 11:Resource temporarily unavailable
(WebKitWebProcess:8630): GStreamer-CRITICAL **: gst_poll_write_control: assertion 'set != NULL' failed
I don't see messages of the "Too many open files" kind but
$ /proc/$i/fd|wc -l
for the WebProcess says 1005 open fds.
The attached file shows them all, in case this can give a clue of what's going on.
Is the network process cache not closing fds after deleting the cached files? (In reply to comment #20) > Is the network process cache not closing fds after deleting the cached files? Problem is not in the network process, but in the web process and we are indeed leaking the shareable resources. In multiprocess mode we kill/destroy processes all the time, so the problem is more difficult to notice, but in single process mode and after long time running, it can happen more easily. I've opened a different bug to fix the leak, since I'm not sure this is the only leak we have or not. Also, even with the leak fixed, we might end up with fds open for a long time, because the shareable resources will be cached by the memory cache. I think the main idea of shareable resources was to avoid sending the data over IPC, but it's also good to avoid data copies, however we might consider copying the data in the web process to release the fd if this is still a problem after fixing the leak. Just now had to kill -9 the Network process. After several days using it, today it exhausted all my memory: 8 Gb RAM and 8 Gb swap. top was showing ~50Gb of VIRT memory used. I could not confirm the reason was, again, the leak in open descriptors since my laptop was almost unusable, swapping all the time. In any case, I suspect that was the case. (In reply to comment #22) > Just now had to kill -9 the Network process. > > After several days using it, today it exhausted all my memory: 8 Gb RAM and > 8 Gb swap. > > top was showing ~50Gb of VIRT memory used. > > I could not confirm the reason was, again, the leak in open descriptors > since my laptop was almost unusable, It wasn't. File descriptors are not actually leaked, but hey stay open while resources are cached in the memory cache. The memory cache lives in the web process, not in the network process. > swapping all the time. In any case, I > suspect that was the case. This looks like a memory leak in the network process instead, the network process releases the file descriptors properly. (In reply to comment #22) > Just now had to kill -9 the Network process. > > After several days using it, today it exhausted all my memory: 8 Gb RAM and > 8 Gb swap. > > top was showing ~50Gb of VIRT memory used. > > I could not confirm the reason was, again, the leak in open descriptors > since my laptop was almost unusable, swapping all the time. In any case, I > suspect that was the case. JFTR I'm suffering the vary same issue, from time to time, my laptop starts to swap like mad making it totally unresponsive. I normally kill the WebProcesses and that fixes the issue. Didn't try to kill NetworkProcess, next time I'll give it a try. Anyway I don't have additional data sorry, just wanted to state that it isn't an Andres-only issue. PS: one interesting thing is that, I need to change to console mode to kill the processes as the UI (GNOME) is totally frozen. When I manage to do that, then the swapping stops. If I switch back to desktop then the swapping is resumed. (In reply to comment #24) ... > PS: one interesting thing is that, I need to change to console mode to kill > the processes as the UI (GNOME) is totally frozen. When I manage to do that, > then the swapping stops. If I switch back to desktop then the swapping is > resumed. In my case, GNOME Shell also gets unresponsive and I also have to move to a console. However, the swapping continues, as shown by "top". Just that the console is, at least, responsive. (In reply to comment #25) > (In reply to comment #24) > ... > > PS: one interesting thing is that, I need to change to console mode to kill > > the processes as the UI (GNOME) is totally frozen. When I manage to do that, > > then the swapping stops. If I switch back to desktop then the swapping is > > resumed. > > In my case, GNOME Shell also gets unresponsive and I also have to move to a > console. However, the swapping continues, as shown by "top". Just that the > console is, at least, responsive. As I said, this is a different issue, please file a new bug report to discuss it. It's surely bug #126122. (In reply to comment #27) > It's surely bug #126122. How is this related to the NetworkProcess? Maybe I'm missing something ... (In reply to comment #28) > How is this related to the NetworkProcess? Maybe I'm missing something ... It's not, sorry, I missed that the fd overuse is causing the hang. Created attachment 282336 [details]
BT from gdb with 2.12.3
I think this is the first time I suffer something similar after wiping out my machine and installing a fresh Debian Testing.
Still, the compilation is done with JHBuild with the same settings than used before.
This time I got a "crashUnableToOpenURandom", I suppose because there were already too many FDs used ...
--
$ ps aux | grep epiph
tanty 2329 0.0 0.0 1728568 4724 tty2 Sl+ Jun23 0:13 /usr/lib/epiphany-browser/epiphany-search-provider
tanty 7627 0.7 2.4 3475228 199116 pts/10 Sl+ Jun28 10:03 /home/tanty/no-backup/personal/webkit/epiphany/install/bin/epiphany
tanty 8018 0.1 0.1 2993572 14320 pts/10 SLl+ Jun28 1:48 /home/tanty/no-backup/personal/webkit/epiphany/install/libexec/webkit2gtk-4.0/WebKitNetworkProcess 14
tanty 8037 2.9 8.0 5185348 651764 pts/10 tl+ Jun28 39:34 /home/tanty/no-backup/personal/webkit/epiphany/install/libexec/webkit2gtk-4.0/WebKitWebProcess 22
tanty 8713 0.1 0.2 3635896 22668 pts/10 Sl+ Jun28 1:46 /home/tanty/no-backup/personal/webkit/epiphany/install/libexec/webkit2gtk-4.0/WebKitPluginProcess2 30 /usr/lib/mozilla/plugins/flash-mozilla.so
tanty 10647 0.0 0.0 16280 296 pts/10 S Jun23 0:00 /bin/bash ./launch-gdb-epiphany.sh --ex r
tanty 10651 0.0 0.0 978728 5588 pts/10 S Jun23 0:36 gdb -ex handle SIG33 pass nostop noprint -ex set pagination 0 ./install/bin/epiphany --ex r
tanty 29144 0.0 0.1 1897384 9708 pts/10 Sl+ Jun28 0:00 /home/tanty/no-backup/personal/webkit/epiphany/install/libexec/webkit2gtk-4.0/WebKitDatabaseProcess 36
tanty 32442 0.0 0.0 15764 2240 pts/21 S+ 12:34 0:00 grep epiph
$ for i in 2329 7627 8018 8037 8713 29144; do ls -l /proc/$i/fd|wc -l; cat /proc/$i/limits; done
13
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size 0 unlimited bytes
Max resident set unlimited unlimited bytes
Max processes 31397 31397 processes
Max open files 1024 65536 files
Max locked memory 65536 65536 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 31397 31397 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us
41
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size 0 unlimited bytes
Max resident set unlimited unlimited bytes
Max processes 31397 31397 processes
Max open files 1024 65536 files
Max locked memory 65536 65536 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 31397 31397 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us
28
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size 0 unlimited bytes
Max resident set unlimited unlimited bytes
Max processes 31397 31397 processes
Max open files 1024 65536 files
Max locked memory 65536 65536 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 31397 31397 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us
1025
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size 0 unlimited bytes
Max resident set unlimited unlimited bytes
Max processes 31397 31397 processes
Max open files 1024 65536 files
Max locked memory 65536 65536 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 31397 31397 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us
31
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size 0 unlimited bytes
Max resident set unlimited unlimited bytes
Max processes 31397 31397 processes
Max open files 1024 65536 files
Max locked memory 65536 65536 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 31397 31397 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us
16
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size 0 unlimited bytes
Max resident set unlimited unlimited bytes
Max processes 31397 31397 processes
Max open files 1024 65536 files
Max locked memory 65536 65536 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 31397 31397 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us
$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 31397
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 31397
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
(In reply to comment #30) > Created attachment 282336 [details] > BT from gdb with 2.12.3 > > I think this is the first time I suffer something similar after wiping out > my machine and installing a fresh Debian Testing. Of course, I'm seeing a lot of: Failed to create shared memory file /WK2SharedMemory.2461067499: Too many open files [9075/9075] Failed to create shared memory file /WK2SharedMemory.3859557170: Too many open files ... In the console. (In reply to comment #30) [snip] > I think this is the first time I suffer something similar after wiping out > my machine and installing a fresh Debian Testing. Just happened again. I won't upload the backtrace since it is very similar ... Created attachment 282768 [details]
Patch
This patch makes WebKitGTK+ release all its file descriptors, see:
- Just opening MB:
before:
$ ls -l /proc/11522/fd | wc -l
27
$ ls -l /proc/11522/fd | grep WebKitCache | wc -l
4
$ ls -l /proc/11522/fd | grep WK2SharedMemory | wc -l
1
after:
$ ls -l /proc/11669/fd | wc -l
22
$ ls -l /proc/11669/fd | grep WebKitCache | wc -l
0
$ ls -l /proc/11669/fd | grep WK2SharedMemory | wc -l
0
- after some navigation
before:
$ ls -l /proc/11783/fd | wc -l
104
$ ls -l /proc/11783/fd | grep WebKitCache | wc -l
79
$ ls -l /proc/11783/fd | grep WK2SharedMemory | wc -l
1
after:
$ ls -l /proc/12093/fd | wc -l
24
$ ls -l /proc/12093/fd | grep WebKitCache | wc -l
0
$ ls -l /proc/12093/fd | grep WK2SharedMemory | wc -l
0
Comment on attachment 282768 [details]
Patch
Clearing flags, unfortunately my assumptions are not always true either :-( I'll try to find a solution.
Created attachment 282771 [details]
Updated patch
It's indeed possible to create multiple handles for the same shared memory, that's what VisitedLinksStore does to send the links map to all web processes. So, we keep always duplicating the file descriptor when creating a handle. The patch still works because the main problem is shared memory objects created to map and existing file that are kept alive as part of caches.
Comment on attachment 282771 [details] Updated patch View in context: https://bugs.webkit.org/attachment.cgi?id=282771&action=review Yay. > Source/WTF/wtf/UniStdExtras.h:51 > +inline bool setCloseOnExec(int fileDescriptor) This is probably too long to be an inline function; you risk reduced performance from increased code size. I would add a .cpp file and move the implementation there. > Source/WTF/wtf/UniStdExtras.h:63 > +inline int dupCloseOnExec(int fileDescriptor) Ditto regarding inline. But also, this function looks like just a replacement for dup3. I think it'd be worthwhile to implement it using dup3 in the #ifdef __linux__ case, and use your current code here only as a fallback. > Source/WTF/wtf/UniStdExtras.h:70 > + Extra blank line here? > Source/WebKit2/ChangeLog:27 > + objects having a valid file descriptor. Use dupCloseOnExec() con duplicate the handle and set the close on exec flag. "con" is not the right word here... did you mean "to"? (In reply to comment #36) > Comment on attachment 282771 [details] > Updated patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=282771&action=review > > Yay. Thanks for the review. > > Source/WTF/wtf/UniStdExtras.h:51 > > +inline bool setCloseOnExec(int fileDescriptor) > > This is probably too long to be an inline function; you risk reduced > performance from increased code size. I would add a .cpp file and move the > implementation there. Ok. > > Source/WTF/wtf/UniStdExtras.h:63 > > +inline int dupCloseOnExec(int fileDescriptor) > > Ditto regarding inline. > > But also, this function looks like just a replacement for dup3. I think it'd > be worthwhile to implement it using dup3 in the #ifdef __linux__ case, and > use your current code here only as a fallback. No, this is not equivalent to dup3, we want dup to chose the new fd for us. > > Source/WTF/wtf/UniStdExtras.h:70 > > + > > Extra blank line here? Yes. > > Source/WebKit2/ChangeLog:27 > > + objects having a valid file descriptor. Use dupCloseOnExec() con duplicate the handle and set the close on exec flag. > > "con" is not the right word here... did you mean "to"? Indeed. Created attachment 283495 [details]
Patch for landing
Attachment 283495 [details] did not pass style-queue:
ERROR: Source/WTF/ChangeLog:12: Need whitespace between colon and description [changelog/filechangedescriptionwhitespace] [5]
Total errors found: 1 in 10 files
If any of these errors are false positives, please file a bug against check-webkit-style.
Committed r203155: <http://trac.webkit.org/changeset/203155> (I'll just mention here that there's an unfixable race condition in non-Linux codepath, where the fd will be leaked if exec occurs before CLOEXEC is set when F_DUPFD_CLOEXEC is unavailable.) |