I'm using WebKitGtk+ with my own JHBuild setting: https://github.com/tanty/jhbuild-epiphany/tree/wkgtk-devel Epiphany 3.18.0 and WebKit 2.10.3 I'm running Epiphany with the dconf key: "process-model" = "shared-secondary-process" The compilation was done with CMake args: '-DPORT=GTK -DCMAKE_BUILD_TYPE=Release -DDEVELOPER_MODE=ON -DCMAKE_C_FLAGS_DEBUG="-O0 -g1" -DCMAKE_CXX_FLAGS_DEBUG="-O0 -g1"' --- Time ago, using "process-model" = "one-secondary-process-per-web-view" I reported the following bug for epiphany: https://bugzilla.gnome.org/show_bug.cgi?id=728352 Basically, I was unable to use this process model because it was using too many file handlers. Today, using: "process-model" = "shared-secondary-process" Eventually, one of the tabs failed to load. No SIGSEVs nor any kind of crashes. This is what I see in the error output: ... Failed to create shared memory file /WK2SharedMemory.2347425006: Too many open files Failed to create shared memory file /WK2SharedMemory.2078275081: Too many open files Failed to create shared memory file /WK2SharedMemory.2879760070: Too many open files Failed to create shared memory file /WK2SharedMemory.3712558436: Too many open files Failed to create shared memory file /WK2SharedMemory.3835635806: Too many open files Failed to create shared memory file /WK2SharedMemory.4122325227: Too many open files Failed to create shared memory file /WK2SharedMemory.1002315265: Too many open files ... This continues for a long, long output. After a while, eventually, the WebProcess SIGSEVed with bug 150899. Maybe these 2 things are unrelated. I don't know. In any case, it seems clear that, even in "shared-secondary-process", WKGTK+ is using too many file descriptors.
(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.)