Adam Thompson <[email protected]> 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.
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.
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;
}
}
Of course, this is all just a theory. Maybe the heap corruption is
coming from elsewhere. But this seems like a plausible candidate.
-- Chris
_______________________________________________
Edbrowse-dev mailing list
[email protected]
http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
