[Edbrowse-dev] js progress update

[Edbrowse-dev] js progress update

[Adam Thompson]

Hi all,

I've now got a version which works with most of the bundled jsrt tests,
I'm just trying to work out why the form buttons cause it to segfault.

There were a bunch of issues,
both the need to use the new rooting api and also the fact that they've changed
the way js compartments and globals interact within individual contexts.
This basicly means that as well as storing a window's context we now have to
store that context's global object as well (at least I've yet to work out a
nicer way of doing this).
This is so the context can be switched into the same compartment as its global object.
I attempted to just switch the context and leave it there but this exploded
spectacularly when going back a page.

Cheers,
Adam.
PS: if you want to see the progress, the repo is at:
https://github.com/arthompson/edbrowse.git

Re: [Edbrowse-dev] js progress update1

[Adam Thompson]

On Tue, Jan 07, 2014 at 12:08:17PM +0000, Adam Thompson wrote:
> PS: if you want to see the progress, the repo is at:
> https://github.com/arthompson/edbrowse.git

Yes, I know I need to run ebindent over everything,
but I was leaving tidying up formatting till I'd finished making large changes.

Re: [Edbrowse-dev] js progress update

[Adam Thompson]

On Tue, Jan 07, 2014 at 12:10:41PM +0000, Adam Thompson wrote:
> On Tue, Jan 07, 2014 at 12:08:17PM +0000, Adam Thompson wrote:
> > PS: if you want to see the progress, the repo is at:
> > https://github.com/arthompson/edbrowse.git
> 
> Yes, I know I need to run ebindent over everything,
> but I was leaving tidying up formatting till I'd finished making large changes.

Ok, I've got a version which builds and runs with my compiled version of mozjs
24 (with --enable-optimize and --disable-debug)
but which segfaults when built against the Debian supplied package.
No idea why this may be, and even with the debugging symbols (libmozjs24d-dbg)
installed it doesn't give me enough info to work out what's breaking.

What I really need to know is how the debian libmozjs24d package is compiled on
amd64 (the architecture of my development box)
so I can check if this is an edbrowse issue or a libmozjs24d debian package issue.
Anyone out there know (or know how I can find out)?

Cheers,
Adam.

Re: [Edbrowse-dev] js progress update

[Chris Brannon]

Adam Thompson <arthompson1990@gmail.com> writes:

> Yeah, particularly if using a debug build of smjs.

Also -- and you may have already discovered this -- it seems that you
need openssl built with -DPURIFY in CFLAGS to make running under
valgrind effective.  Otherwise, you get a bunch of spurious
"uninitialized value" errors caused by openssl.  I've started running
under valgrind.  So far, the only memory leak I've found is not
JS-related at all; it's in htmlAttrVal.  I believe it's caused by
returning NULL / 0 in the middle of the function without calling nzFree
on a now-unreachable allocated string.
So I'll keep on testing for other leaks.

PS.  I managed to crash the latest yesterday, running under mozjs 24,
while browsing netflix.com.  I couldn't repeat it, though.

-- Chris

Re: [Edbrowse-dev] js progress update

[Adam Thompson]

On Tue, Jan 14, 2014 at 02:17:40PM -0800, Chris Brannon wrote:
> Adam Thompson <arthompson1990@gmail.com> writes:
> 
> > We also need to work out a good way of testing for memory leaks,
> > I was thinking of running under valgrind for extended periods of web browsing.
> 
> It's a good idea.  I found lots of memory leaks this way in the past,
> along with a couple memory corruption bugs.
> Browsing under valgrind is a little more sluggish, as one would expect,
> but it isn't terrible by any means.

Yeah, particularly if using a debug build of smjs.

I still haven't heard back about the debian package,
and am still no nearer figuring out what's going on there.
The segfault seems to be in something called as a consequence of the
JS_NewContext function, which doesn't break in any of the SpiderMonkey builds
I've done, even the ones with optimisations enabled and debugging disabled.

I've uncovered a very interesting js bug with this version of edbrowse though,
where it sometimes fails to initialise the standard classes for the jwin object.
I'm trying to work out exactly why this is the case,
however university assignments are reducing the speed of debugging at the moment.
It may be worth checking that I've always done the right thing regarding
setting jwin to the correct object and setting the correct compartment for the
js context.
Unfortunately it looks as if each new global object gets its own compartment
now and the only way I've managed to get the compartment to be switched
reliably is to switch at the start of each function which needs to use the global object.
This isn't particularly nice and needs cleaning up when we do the major rewrite.

Cheers,
Adam.

Re: [Edbrowse-dev] js progress update

[Chris Brannon]

Adam Thompson <arthompson1990@gmail.com> writes:

> We also need to work out a good way of testing for memory leaks,
> I was thinking of running under valgrind for extended periods of web browsing.

It's a good idea.  I found lots of memory leaks this way in the past,
along with a couple memory corruption bugs.
Browsing under valgrind is a little more sluggish, as one would expect,
but it isn't terrible by any means.

-- Chris

Re: [Edbrowse-dev] js progress update

[Adam Thompson]

On Tue, Jan 14, 2014 at 12:43:32PM -0800, Chris Brannon wrote:
> Adam Thompson <arthompson1990@gmail.com> writes:
> 
> > Thanks, will do. Whilst I do this, is there any chance people could test my
> > fork of edbrowse as well?
> 
> Sorry, I had a bit of a rough week, so I haven't really had a chance to
> look at this.  It builds for me.  I'll try and test and review in the
> next couple of days.

Thanks, hope things improve for you. I think there're still some js related bugs there,
but they're hard to trigger. I'm not sure if they're gc-related or not.
I'm also not sure if they were already present or if they're new.
All I know (discovered after I sent my last email) is that
it does occasionally seem to segfault,
and I also got an error caused by a NULL jwin pointer (not managed to reproduce this one).
We also need to work out a good way of testing for memory leaks,
I was thinking of running under valgrind for extended periods of web browsing.

Cheers,
adam.

Re: [Edbrowse-dev] js progress update

[Chris Brannon]

Adam Thompson <arthompson1990@gmail.com> writes:

> Thanks, will do. Whilst I do this, is there any chance people could test my
> fork of edbrowse as well?

Sorry, I had a bit of a rough week, so I haven't really had a chance to
look at this.  It builds for me.  I'll try and test and review in the
next couple of days.

Thanks,
-- Chris

Re: [Edbrowse-dev] js progress update

[Adam Thompson]

On Wed, Jan 08, 2014 at 06:05:51AM -0500, Karl Dahlke wrote:
> > so I can check if this is an edbrowse issue or a libmozjs24d debian package issue.
> 
> I would contact Jean, who contacted me in the first place.
> He wants edbrowse in debian, and discovered the problem building against moz26.
> He may know how those libraries are built and packaged etc.
> He is French, but his English is perfect!
> 
> mengualjeanphi@free.fr

Thanks, will do. Whilst I do this, is there any chance people could test my
fork of edbrowse as well? The Spidermonkey 24 build process is relatively
painless, and it'd be *extremely* useful as I *think* I've squashed all the
obvious bugs, but there are probably many I've missed.
I'm now running this as my default edbrowse (so default editor and web browser)
so hopefully I'll discover various things,
but obviously the more testing the better.
Also, I've reformatted the code and pushed the commit,
so hopefully it should be ok for merging into the main code base soon.

As always, any feedback (especially code review) is very welcome.

Cheers,
Adam.

[Edbrowse-dev] js progress update

[Karl Dahlke]

> so I can check if this is an edbrowse issue or a libmozjs24d debian package issue.

I would contact Jean, who contacted me in the first place.
He wants edbrowse in debian, and discovered the problem building against moz26.
He may know how those libraries are built and packaged etc.
He is French, but his English is perfect!

mengualjeanphi@free.fr

Karl Dahlke