On Fri, Sep 02, 2011 at 01:48:29PM -0300, Jorge Arellano Cid wrote:
On Fri, Sep 02, 2011 at 03:59:17PM +0000, corvid wrote:
Jorge wrote:
On Thu, Sep 01, 2011 at 07:47:48PM +0000, corvid wrote:
Jorge wrote:
On Thu, Sep 01, 2011 at 10:56:19AM -0300, Jorge Arellano Cid wrote:
[...] Any help is appreciatted.
My guess is that it could be something like first, one bw asks for a page, and that becomes conn->bw, and then another bw starts also asking for the page, and the first bw closes, invalidating the conn->bw, and then the second bw closes and the cancel expect code tries to use the old bw.
"bw" is a bit a misleading name, bacause each tab is a bw.
OTOH, each tab has its own control panel and thus becomes a browser window object.
In the case you propose there'd be two different bw.
Right. Why do you feel that they can't be two bws that were both closed from the keyboard?
I have no problems with that.
What I don't see is two bws with the same memory address being closed from the keyboard.
But now I see what you mean: which is a lingering bw in conn, (which is compatible with my analysis), as there's no need for it to exist in the UI when the event arrives.
So we'de have two close events handled OK by two perfectly sane bws, but one call made on an already defunct bw (i.e. not present in the UI).
And you hit it on the nail, because now I can reproduce it!!!
Patch committed. FWIW, the testcase I used produced: ==17336== ERROR SUMMARY: 115 errors from 76 contexts (suppressed: 13 from 10) without the patch, and ==17468== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 10) with it. :-) -- Cheers Jorge.-