From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by hurricane.the-brannons.com (Postfix) with ESMTPS id E6093784A2 for ; Wed, 19 Feb 2014 08:53:44 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hm4so826217wib.13 for ; Wed, 19 Feb 2014 08:52:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=pt0LVshXbTM8gIDkBjsmO3r+B5uiBpmkCcLi2FI0Oeg=; b=sRYaLYpnEeBmQVk4Yw32uHzisHTNLP3ZQkBkuP2IEb//feFSb7XLmpnqFokhwxcTc3 Hc2iYdrQpd24h8jUlgvN8+7H4k3ANJgBaB+2dZh8s2jGwNJDHdAu8arV8wS4YZORCTgD xoTkiJsrgcDTZtZUld84q8cFNvwFznCvt4gPg/Z8Bzf1ppUUeTztTbiUwxWeMbk0TzH7 /aJ4/IypitSgCqpxCTb8bh7qsDHVV3OAc+0hhnQj/EL/ad+cCaQj43LZ3BUquYz/opUJ ipqcCYtWIc4CmECFBpfeN43TzJWmM9Pq4ZKtTVPxudm9O/G4PqcfhFgieBm7J6iDi2Hn 4T7A== X-Received: by 10.180.188.66 with SMTP id fy2mr2459729wic.45.1392828769414; Wed, 19 Feb 2014 08:52:49 -0800 (PST) Received: from toaster.adamthompson.me.uk (toaster.adamthompson.me.uk. [2001:8b0:1142:9042::2]) by mx.google.com with ESMTPSA id di9sm3226913wid.6.2014.02.19.08.52.47 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 19 Feb 2014 08:52:48 -0800 (PST) Date: Wed, 19 Feb 2014 16:52:45 +0000 From: Adam Thompson To: Chris Brannon Message-ID: <20140219165245.GL28870@toaster.adamthompson.me.uk> References: <20140119042137.eklhad@comcast.net> <20140219113807.GJ28870@toaster.adamthompson.me.uk> <20140219141237.GK28870@toaster.adamthompson.me.uk> <87lhx76q7z.fsf@mushroom.PK5001Z> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87lhx76q7z.fsf@mushroom.PK5001Z> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Edbrowse-dev@lists.the-brannons.com Subject: Re: [Edbrowse-dev] segfault with small pool X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.17 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 16:53:45 -0000 On Wed, Feb 19, 2014 at 08:07:28AM -0800, Chris Brannon wrote: > Adam Thompson 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