Advice requested for fixing issue 17914

[Nemanja Boric]

On Wednesday, 25 October 2017 at 15:43:12 UTC, Steven 
Schveighoffer wrote:
> On 10/25/17 11:27 AM, Nemanja Boric wrote:
>> On Wednesday, 25 October 2017 at 15:22:18 UTC, Nemanja Boric 
>> wrote:
>>> On Wednesday, 25 October 2017 at 15:12:27 UTC, Nemanja Boric 
>>> wrote:
>>>> On Wednesday, 25 October 2017 at 14:19:14 UTC, Jonathan M 
>>>> Davis wrote:
>>>>> On Wednesday, October 25, 2017 09:26:26 Steven 
>>>>> Schveighoffer via Digitalmars-d wrote:
>>>>>> [...]
>>>>>
>>>>> Maybe there was a change in the OS(es) being used that 
>>>>> affected the limit?
>>>>>
>>>>> - Jonathan M Davis
>>>>
>>>> Yes, the stack is not immediately unmapped because it's very 
>>>> common
>>>> just to reset the fiber and reuse it for handling the new 
>>>> connection -
>>>> creating new fibers (and doing unmap on termination) is a 
>>>> problem in the
>>>> real life (as this is as well).
>>>>
>>>> At sociomantic we already had this issue: 
>>>> https://github.com/sociomantic-tsunami/tangort/issues/2 
>>>> Maybe this is the way to go - I don't see a reason why every 
>>>> stack should be mmaped separately.
>>>
>>> I'm not sure that would allow us to mprotect the page guards, 
>>> though.
>> 
>> I think the easiest way to proceed from here is to default the 
>> stack protection page to 0, so we avoid this regression. Once 
>> that's in, we can think about different allocation strategy 
>> for the fiber's stacks or throwing the exceptions on too many 
>> fibers (too bad mmap doesn't return error code, but you get 
>> SIGABRT instead :( )
>
> mmap does return an error. And onOutMemoryError is called when 
> it fails.
>
> https://github.com/dlang/druntime/blob/master/src/core/thread.d#L4518
>
> Which should throw an error:
>
> https://github.com/dlang/druntime/blob/144c9e6e9a3c00aba82b92da527a52190fe91c97/src/core/exception.d#L542
>
> however, when mprotect fails, it calls abort():
>
> https://github.com/dlang/druntime/blob/master/src/core/thread.d#L4540
>
>> What do you think?
>
> I think we should reverse the mprotect default, and try and 
> determine a better way to opt-in to the limit.
>
> Is this a Linux-specific problem? Are there issues with 
> mprotect on other OSes? Or is Linux the only OS that supports 
> mprotect?
>
> -Steve


Reading FreeBSD man pages, it looks like at least FreeBSD has the 
same limitation in the mmap, but the man pages for the mprotect 
doesn't specify this. However, I believe it's just the issue in 
the man pages, as it would be the same thing really as with 
Linux. Linux's manpage for mprotect specifically says this:

>        ENOMEM Changing the protection of a memory region would 
> result in the
               total number of mappings with distinct attributes 
(e.g., read
               versus read/write protection) exceeding the allowed 
maximum.
               (For example, making the protection of a range 
PROT_READ in
               the middle of a region currently protected as
               PROT_READ|PROT_WRITE would result in three 
mappings: two
               read/write mappings at each end and a read-only 
mapping in the
               middle.)

so I was right about doubling the mappings.

> > I think we should reverse the mprotect default, and try and
> determine a better way to opt-in to the limit.

I agree: https://github.com/dlang/druntime/pull/1956