[haiku-commits] Re: BRANCH midar-github.master - src/preferences/bluetooth src/servers/app src/kits/tracker src/add-ons/screen_savers/message headers/os/support
- From: François Revol <revol@xxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Tue, 20 Nov 2012 16:26:04 +0100
On 20/11/2012 14:03, Ingo Weinhold wrote:
>>> I don't understand this conclusion. Why would it crash when running
>>> out of virtual address space? If all allocations are checked, there's
>>> no reason why the program should misbehave.
>>
>> If the MMU can't even map something anymore, it means the process
>> already has to use gigabytes of memory - more than you could ever have
>> using actual memory. This means something went berserk and allocates
>> in a loop or something. The exception would then finally terminate it.
>
> OK, I see. The conclusion is not that because of the exhaustion of
> address space something will crash, but that the something that led to
> the exhaustion of address space will also cause a crash. In case of the
> app server that isn't necessarily so. E.g. memory for bitmaps allocated
> by clients is also mapped in the app server address space. So in 32 bit
> mode it is relatively easy to exhaust without anything going wrong in
> the app server itself. Crashing the app server in such a case wouldn't
> be helpful.
Indeed, returning an error should get the application to notice and
either hang or terminate, freeing enough resources for other apps and
the server to continue...
>
>>> A scenario where it actually can crash is when running out of
>>> physical memory, since we over-commit our stacks. Ideally we would
>>> deal with that situation gracefully as well, though that isn't
>>> entirely trivial.
>>
>> That can't be caught anyway. new returns a pointer, even if no memory
>> is available. On the first write, the memory is actually allocated.
>
> Well, it is possible to catch the SIGSEGV. Properly handling it so that
> everything is brought back to a well-defined state and the thread can
> continue is rather involved, though. Obviously the whole situation can
> be prevented by committing physical memory for the app server threads'
> stack beforehand.
Nothing to do with new() anyway, if you use the nothrow version it will
return a NULL that you can check for.
But new() doesn't allocate on stack but on the heap, which as Ingo said
is committed.
As for stacks well that's a different thing indeed.
François.
Other related posts:
