On Sun, Feb 09, 2014 at 10:45:25AM +0000, Adam Thompson wrote: > On Fri, Feb 07, 2014 at 10:23:05AM -0800, Chris Brannon wrote: > > Karl Dahlke <[email protected]> writes: > > > My gut tells me the segfaults might come from somewhere else. > > So it is failing with out-of-memory in this case. I'm sure youtube is a > > very JS-intensive site, but could there be another reason for the memory > > exaustion? I don't know. > > Not sure, we really need to go through everything and ensure that what needs > to > be rooted is and what doesn't isn't. > Incidentally I bumped my jspool limit up to 64 meg and that example works now. > Really it'd be much nicer if we could get js to dynamically grow to deal with > this (with an *optional* limit). > > I'd still prefer it if it just killed the offending context as well > (js_DestroyContext and js_GC?). This should mean that everything else can > continue and we reclaim the lost memory, > or in the worst case just the js side is broken. > Either way, it allows the user to save critical work, bookmark pages etc. > At the moment, although I agree that not segfaulting is much nicer, > the overall outcome is the same; edbrowse goes away taking your unsaved work > and other browsing sessions with it. > I can try and implement this if people agree.
Looking at the docs it looks like this can't be done inside the error reporter, and at any rate, I've still seen (whilst trying to browse the docs) more js-related segfaults (with no helpful errors though). All this is pushing me back to doing the error leg stuff properly rather than in the error reporter. That, and the fact that according to the docs, any function which returns a value and takes a js context pointer can (depending on return) return either false or NULL to indicate failure. I assume by this they mean they're not going to make explicit the failure conditions for these functions, just that failure is always an option in these cases. They do also say that such failures aren't always due to out of memory conditions, and may be due to such things as syntax errors etc. Cheers, Adam. _______________________________________________ Edbrowse-dev mailing list [email protected] http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
