From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 7734077AAF for ; Mon, 6 Jan 2014 05:06:09 -0800 (PST) Received: by mail-we0-f169.google.com with SMTP id w61so15959286wes.14 for ; Mon, 06 Jan 2014 05:05:53 -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=kc5wPnGSyrVibbgHFvzPD+PzaEH/fU6ndcKBR2SL/8E=; b=uikb/xp6pgQ5gBq0Y1ae15gZgx4bh2XzaOnOhCBlxkzvGN/Hp3rQV7ePIzk9+bDZVj JBHLLncLBhUCNDyl/IhCkuE+FvbIsGmAicjL8ZWKxw0KoXcdIIHIsRbVq/Euu9vAcT+9 mLYNuP4IHOXByPE11/uF7N34GhFPtRYwPkjgbcM3kXeRsm/Ckct2uMRq59OFEWq6ZIn5 6CAB7nc0MmRacU96KCog8bbXkJpmXHgrK9pDaQHGBQY0EI5gDaq2TS4e/2NlZBcb4z0Y i3PsNPAn99wAvlEG7SxbnHM2AXSojRXM+08VflprNaU0kZgfUdAYW9fCQc5lR67Eb+zO g94Q== X-Received: by 10.180.12.146 with SMTP id y18mr12430308wib.37.1389013552554; Mon, 06 Jan 2014 05:05:52 -0800 (PST) Received: from toaster.adamthompson.me.uk (toaster.adamthompson.me.uk. [2001:8b0:1142:9042::2]) by mx.google.com with ESMTPSA id a9sm17814357wiy.10.2014.01.06.05.05.51 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 06 Jan 2014 05:05:51 -0800 (PST) Date: Mon, 6 Jan 2014 13:05:48 +0000 From: Adam Thompson To: Karl Dahlke Message-ID: <20140106130548.GI11201@toaster.adamthompson.me.uk> References: <20140006051913.eklhad@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140006051913.eklhad@comcast.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Edbrowse-dev@lists.the-brannons.com Subject: Re: [Edbrowse-dev] window root 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: Mon, 06 Jan 2014 13:06:09 -0000 On Mon, Jan 06, 2014 at 05:19:13AM -0500, Karl Dahlke wrote: > > For example the JS_ValueToString function explicitly says > > that you should protect its return value with a GC root or the string is > > at risk of garbage collection at any stage. > > Well edbrowse is not multithreaded. > Within the one and only thread, I immediately make that js value > a property in some other object; I immediately link it to the window tree. > That's why I made it a js string in the first place. > Thus it is referenced. > I keep thinking there should be no trouble. Maybe not, but the docs talk about the need for rooting in single-threaded builds as well as thread safe ones. It's not helped by the fact that the api seems to have changed between the documents being written (even with the post 185 updates) and the version of mozjs 24 I grabbed from the website. It looks like the GC is ran in the same thread as everything else, but is now called by more functions internally hence the need for more rooting. > > Admittedly some of this rooting may be paranoia, > > And that's ok, I guess, unless we are setting up excess reference counts, > and those objects never go away, even when they aren't used any more, > because the reference count never drops to 0, > and edbrowse has memory leaks. > People like me really are in edbrowse for hours at a time. > So I'm not sure we should swing the big hammer and root everything. > At an intellectual level I'd like to know why everything isn't > already rooted to jswin. Yeah, I know we have to be *very* careful about memory leaks, particularly as I routinely use edbrowse for extended periods of time. > > Of course you're doing all the work, not me, > and if rooting everything will get us off the ground, > and get rid of seg faults, > then we can watch for and fix memory leaks later. > I do understand that sometimes you just have to move forward. Yeah, which is made harder by the fact that, by there own admition, the mozilla devs regularly change the api in fundimental ways. I'm just rebuilding a version of smjs 24 with as much debugging info as I can so I can go through everything with gdb to try and work out exactly what's still breaking. Cheers, Adam. PS: the only place I can find any mention of SpiderMonkey 26 is in Debian packages, and the version of the development headers for libmozjs26d (the experimental debian package for SpiderMonkey 26) has a broken symlink instead of jsapi.h so building against it is currently impossible