https://issues.dlang.org/show_bug.cgi?id=17914
Steven Schveighoffer <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #3 from Steven Schveighoffer <[email protected]> --- (In reply to Martin Nowak from comment #2) > 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. This would explain why the limit wasn't being reached before the change! > I'd err on the side of memory safety. Stack overflows are an actual problem > with Fibers and hard&time-consuming to debug. Except this breaks existing code that may not have a stack overflow problem. I hate to say it, but unfortunately, we are stuck with the status quo for now. > Any better idea to detect/prevent stack overflows? A possible idea is putting a pattern in the guard data (leave it read/write), and check the guard data on fiber deallocation, and optionally on every yield (could be a performance issue, but maybe only used in debug mode?) You can also check the current SP on yield to make sure it's in-bounds (cheap but doesn't cover everything). Another option is to put a read-only guard page on only some of the fibers. If you are allocating a lot of similar fibers, you are bound to hit one eventually. Still another option is to allocate the guard page on as many fibers as you can, and then back off when you can't. This could be difficult, however, as the relationship between mmap'd regions and the number of fibers may not be linear. None of this prevents 100% of corruption, but they are better than nothing. --
