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

[Adam Thompson <arthompson1990@gmail.com>]

On Fri, Feb 07, 2014 at 01:30:51AM -0500, Karl Dahlke wrote:
> > 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.

This is probably the case.

> 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.

No it doesn't, I've got a feeling that's a broken debian package.
I'm going to look at this more over the weekend.

> > 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.

Yeah, that's certainly unfortunate.

> 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.

May as well do this for all machines, or just not bother.
On 32 bit machines, can you really get enough ram to exhaust 32 bit size_t?

> 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.

I think keep the focus on js 24 for the minute,
with a focus on the size_t change after the release.
At the end of the day if the back end is stable then adding dom objects etc is
much easier. Also, as long as the api remains somewhat the same (with int
switched for size_t) people can be working on both things at once.

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

Thanks for providing such a useful program.

Cheers,
Adam.