[Edbrowse-dev] suggest increasing the size argument to JS_NewRuntime

[Karl Dahlke <eklhad@comcast.net>]

> From what I can tell, the remaining segfaults all seem to be caused by
> out-of-memory errors in JS.

Really?
JS is so bad that when it exhausts its memory pool it segfaults?
That doesn't give me a warm fuzzy feeling.

Or maybe js returns 0, like any malloc failure,
and I don't watch for that and then I segfault.
If that is the case then we need to write lots more error legs,
which is really tedious programming.

Sure, push the run time memory up to 32 or 64 meg. Why not?
Probably can't buy a computer these days with under 4 gig,
or even a smart phone.
But that doesn't explain why Chris simple program segfaults on debian js.

> As an aside, with debug level 2 or greater,
> edbrowse will print "out of memory" before it crashes.

Not sure what this means.
My wrappers around malloc do indeed print and exit upon malloc failure,
which probably saves me about 3,000 lines of error leg programming,
but you don't need debug levels, it just happens.
However ... on a 64 bit machine with lots of memory,
integers could overflow before we are out of ram.
Even though it's a signed int, malloc prototype is size_t, which is unsigned,
so we're really good all the way up to unsigned in, however,
beyond that we are allocating a really small number,
instead of 4 gig, and then we tromp over unallocated memory, and that's bad.
Remember that edbrowse was originally written when the best computer
on the market had 64 meg.
So I need to revamp all these strings and allocated arrays, and use size_t,
and then for the 32 bit machines, make sure there is no size_t overflow.
A file with half a billion lines, times sizeof(struct lineMap),
goes over the limit.
Plenty to think about here, but perhaps more important is
putting in more dom objects and functions to support more websites.
But we should probably remain focused on js 24 and the next release.

Thank you so much for all your help and hard work.

Karl Dahlke