[Issue 17914] [Reg 2.075] Fibers guard page uses a lot more memory mappings

d-bugmail at puremagic.com d-bugmail at puremagic.com
Thu Oct 26 17:18:22 UTC 2017


https://issues.dlang.org/show_bug.cgi?id=17914

Martin Nowak <code at dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code at dawg.eu
            Summary|Accidental per-process      |[Reg 2.075] Fibers guard
                   |limit of fiber uses         |page uses a lot more memory
                   |                            |mappings

--- Comment #2 from Martin Nowak <code at dawg.eu> ---
Here is what I'm seeing, calling mprotect splits the mapped range into 2, a 16K
rw--- and a 4K ----- mapping.
Calling GC.collect finalizes all unreachable Fibers and unmaps *both* regions
with a single `munmap(p, 20K)` call, so we don't really leak anything here.

What's actually causing the limit is the fact that the kernel can no longer
merge the mappings, hence the limit gets reached much quicker.


foreach (i; 0 .. 32 * 1_024) { new Fiber(function{}, 4 * 4096, 0); }

00007f63304e9000 123184K rw---   [ anon ]

vs.

foreach (i; 0 .. 32 * 1_024) { new Fiber(function{}, 3 * 4096, 4096); }

00007f2819cbf000     12K rw---   [ anon ]
00007f2819cc2000      4K -----   [ anon ]
00007f2819cc3000     12K rw---   [ anon ]
00007f2819cc6000      4K -----   [ anon ]
00007f2819cc7000     12K rw---   [ anon ]
00007f2819cca000      4K -----   [ anon ]
00007f2819ccb000     12K rw---   [ anon ]
00007f2819cce000      4K -----   [ anon ]
00007f2819ccf000     12K rw---   [ anon ]
00007f2819cd2000      4K -----   [ anon ]
00007f2819cd3000     12K rw---   [ anon ]
00007f2819cd6000      4K -----   [ anon ]

I'd err on the side of memory safety. Stack overflows are an actual problem
with Fibers and hard&time-consuming to debug.
For using 32K+ Fibers it doesn't seem too reasonable to use custom stack and
guard sizes, e.g. a fairly big default stack size without guard page would
prevent most issues.

Any better idea to detect/prevent stack overflows?

--


More information about the Digitalmars-d-bugs mailing list