Bad array indexing is considered deadly

Laeeth Isharc via Digitalmars-d digitalmars-d at puremagic.com
Thu Jun 1 19:11:34 PDT 2017


On Wednesday, 31 May 2017 at 13:34:25 UTC, Steven Schveighoffer 
wrote:
> On 5/31/17 9:21 AM, H. S. Teoh via Digitalmars-d wrote:
>> On Wed, May 31, 2017 at 09:04:52AM -0400, Steven Schveighoffer 
>> via Digitalmars-d 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.
>> [...]
>>
>> Isn't it customary to have the webserver launched by a script 
>> that
>> restarts it whenever it crashes (after logging a message in an 
>> emergency
>> logfile)?  Not an ideal solution, I know, but at least it 
>> minimizes
>> downtime.
>
> Yes, I can likely do this. This kills any existing connections 
> being handled though, and is far far from ideal. It's also a 
> hard crash, any operations such as writing DB data are killed 
> mid-stream.
>
>..
> -Steve

Hi Steve.

Had similar problems early on.  We used supervisord to 
automatically keep a pool of vibed applications running and put 
nginx in front as a load balancer. User session info stored in 
redis.  And a separate process for data communicating with web 
server over nanomsg.  Zeromq is more mature but I found sometimes 
socket could get into an inconsistent state if servers crashed 
midway, and nanomsg doesn't have this problem. So data update 
either succeeds or fails but no corruption if Web server crashes.

Maybe better ways but it seems to be okay for us.


Laeeth



More information about the Digitalmars-d mailing list