Bad array indexing is considered deadly

[Andrei Alexandrescu via Digitalmars-d]

On 05/31/2017 09:04 AM, Steven Schveighoffer wrote:
> I have discovered an annoyance in using vibe.d instead of another web 
> framework. Simple errors in indexing crash the entire application.
> 
> For example:
> 
> int[3] arr;
> arr[3] = 5;
> 
> Compare this to, let's say, a malformed unicode string (exception), 
> malformed JSON data (exception), file not found (exception), etc.
> 
> Technically this is a programming error, and a bug. But memory hasn't 
> actually been corrupted. The system properly stopped me from corrupting 
> memory. But my reward is that even though this fiber threw an Error, and 
> I get an error message in the log showing me the bug, the web server 
> itself is now out of commission. No other pages can be served. This is 
> like the equivalent of having a guard rail on a road not only stop you 
> from going off the cliff but proactively disable your car afterwards to 
> prevent you from more harm.
> 
> This seems like a large penalty for "almost" corrupting memory. No other 
> web framework I've used crashes the entire web server for such a simple 
> programming error. And vibe.d has no choice. There is no guarantee the 
> stack is properly unwound, so it has to accept the characterization of 
> this is a program-ending error by the D runtime.
> 
> I am considering writing a set of array wrappers that throw exceptions 
> when trying to access out of bounds elements. This comes with its own 
> set of problems, but at least the web server should continue to run.
> 
> What are your thoughts? Have you run into this? If so, how did you solve 
> it?

This is a meaningful concern. People use threads instead of processes 
for serving requests for improving speed and footprint. Threads hardly 
communicate with one another so they are virtually independent. D 
already has good mechanisms for isolating threads effectively (the 
shared qualifier, @safe) so an argument could be made that bringing down 
the entire process because a thread has had a problem is 
disproportionate response.

This was a concern about using D on the server for Facebook as well.

Of course, it may be the case that that thread's failure reflects a 
memory corruption that affects all others, so one could reduce the 
matter to this and argue the entire process should be brought down. But 
of course things are never as simple as we'd like them to be.

Array bound accesses should be easy to intercept and have them just kill 
the current thread. Vibe may want to do that, or allow their users to. 
The more difficult matter is null pointer dereferences. I recall there 
has been work in druntime to convert memory violations into thrown 
Errors at least on Linux. You may want to look into that.

It seems to me we'd do good to improve matters on this front.


Thanks,

Andrei