Re: [Edbrowse-dev] segfault with small pool

[Adam Thompson <arthompson1990@gmail.com>]

On Wed, Feb 19, 2014 at 08:07:28AM -0800, Chris Brannon wrote:
> Adam Thompson <arthompson1990@gmail.com> writes:
> 
> > I'm now seeing a segfault in encodeTags relating to a stringAndChar call.
> > I'm having a go at debugging this, but it's a realloc segfault
> 
> What you're seeing is heap corruption.  I'm seeing a similar segfault in
> malloc, called by allocZeroMem, called by newTag.
> I have no idea what's causing it either, but I do have a theory.  After
> the call to javaSessionFail(), we have lots of objects: JS::Rooted,
> JS::Handle, JS::HeapRooted, and so forth, and they're still on the stack
> or heap.  And they now reference a destroyed JSContext *.  The heap
> corruption comes about when their destructors are called.

I agree, after further debugging using valgrind,
gdb and also the electric fence library [1],
it looks like a case of heap corruption.

> There's no easy fix for the stack-allocated stuff, I think.  We have to
> insure that we don't have any dangling JS::Handle or JS::Rooted when we
> call javaSessionFail.

I'm not sure if that's even possible at the moment given the way some of the
functions work. I'd hope that what happens when we destroy the context is that
the context-linked roots also go away (which'd make sense).
Otherwise, I don't know how we can fix this.

> As for the heap-rooted objects, maybe javaSessionFail could traverse the
> tag list before the context is destroyed, eliminating all of our
> references.  I'd put this logic into a function in html.cpp, since the
> tag list is private to that file.  For example, it could look like this.
> 
> void freeHeapRooted(void) {
> for tag in tag_list {
> tag->ev = NULL;
> }
> }

As Karl says, this should be ok as far as not destroying heap rooted things goes.

> 
> Of course, this is all just a theory.  Maybe the heap corruption is
> coming from elsewhere.  But this seems like a plausible candidate.

I know when running with electric fence it aborts at JS_NewContext (same as the
debian segfault, I wonder), so I've got a suspician smjs has a few more hidden 
issues.
Whether these are causing ours I'm not sure.

I'll have a go at working out a way round the stack issue though.

Cheers,
Adam.
[1] http://en.wikipedia.org/wiki/Electric_Fence