Chrome Version       : 64.0.3282.140

This issue was originally posted on the patchset that caused the regression - https://chromium-review.googlesource.com/c/chromium/src/+/781160/#message-6a6fa9251f422507a88181b72c1b817f176b378f - here follows a copy of that description:

`fdopen` will allocate a `FILE` that is leaked, but that's only part of the problem.

The glibc implementation of `fork` will touch all `FILE`s [0] in the child process, defeating CoW and causing the copy of a significant portion of the parent heap.
Every time an `exec` is needed (e.g. for file open/save dialogs), the child process can easily OOM (given a long-running browser) inside `fork`, before it can get to the `exec`.

On Linux at least, processes with names starting with "TaskScheduler" can be observed as they quickly grow their memory usage, and I believe a thread I've found on the Google Chrome Help Forum [1] refers to this exact problem, as well.

In general, I would avoid `FILE` as much as possible, as implementations appear to be quite inefficient and potentially disruptive.


[0] https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/nptl/fork.c;h=ec56a827eba483b6a6e3226a8c4ba7e1199d10a5;hb=HEAD#l37
[1] https://productforums.google.com/forum/#!msg/chrome/IjeicWOeYlo/uRoHbdU6BQAJ