[Edbrowse-dev] 24

[Edbrowse-dev] 24

[Karl Dahlke]

> I also need to work out why the debian mozjs24d package causes edbrowse
> to just segfault on startup whereas a manually compiled one doesn't

This is I think the greatest concern with cutting a new release.
We started this effort to get it working with 24,
and that is still uncertain.

I found this in the source/README

This release is based on a revision of Mozilla 24:
  http://hg.mozilla.org/releases/
The changes in the patches/ directory were applied.

Maybe some of those changes are important / critical,
for the way we are using it.

Karl Dahlke

Re: [Edbrowse-dev] 24

[Chris Brannon]

Karl Dahlke <eklhad@comcast.net> writes:

>> I also need to work out why the debian mozjs24d package causes edbrowse
>> to just segfault on startup whereas a manually compiled one doesn't

It fails in a function called indirectly from JS_NewContext.  The
failure seems to be in mozilla::HashBytes.  For some odd reason, I can't
trace that function with gdb, even though I have debugging symbols
compiled in.

-- Chris

Re: [Edbrowse-dev] 24

[Adam Thompson]

On Wed, Feb 05, 2014 at 08:35:52PM -0800, Chris Brannon wrote:
> Karl Dahlke <eklhad@comcast.net> writes:
> 
> >> I also need to work out why the debian mozjs24d package causes edbrowse
> >> to just segfault on startup whereas a manually compiled one doesn't
> 
> It fails in a function called indirectly from JS_NewContext.  The
> failure seems to be in mozilla::HashBytes.  For some odd reason, I can't
> trace that function with gdb, even though I have debugging symbols
> compiled in.

Yeah, the debian package's debugging symbols reference iceweasel source which
isn't in the package (and at any rate the reference is to /tmp).
In addition, the packaged lib is compiled with optimisations making debugging...
interesting... even when the debugging symbols actually work.
These difficulties were the main motivation behind using my own compiled mozjs24.

Should this be reported as a bug against the package,
or is this segfault an edbrowse problem do you think?

Cheers,
Adam.
PS: the mozjs26d package is still broken so no chance of building against that.

Re: [Edbrowse-dev] 24

[Chris Brannon]

Adam Thompson <arthompson1990@gmail.com> writes:

> Yeah, the debian package's debugging symbols reference iceweasel source which
> isn't in the package (and at any rate the reference is to /tmp).

That's easy.
mkdir /tmp/buildd
cd /tmp/buildd
apt-get source libmozjs
And now you can step through the mozjs source.
But the optimizations still make mozilla::HashBytes untraceable.

> Should this be reported as a bug against the package,

I honestly don't know.  I've had problems with Debian's spidermonkey
package in the past.  Years ago, to compile on Debian, I had to pass a C
preprocessor define, so that the layout of Spidermonkey structs was the
same as the one Debian was using.  -DMOZILLA_1_8_BRANCH, I think it
was.  I wouldn't be surprised if there was an issue in their package,
but I really don't know for sure.
I also tried compiling a "Hello world" spidermonkey application, and it
segfaults in the same place.  Here it is:
http://the-brannons.com/jshello.cpp

-- Chris

Re: [Edbrowse-dev] 24

[Adam Thompson]

On Thu, Feb 06, 2014 at 07:29:06AM -0800, Chris Brannon wrote:
> Adam Thompson <arthompson1990@gmail.com> writes:
> 
> > Yeah, the debian package's debugging symbols reference iceweasel source which
> > isn't in the package (and at any rate the reference is to /tmp).
> 
> That's easy.
> mkdir /tmp/buildd
> cd /tmp/buildd
> apt-get source libmozjs
> And now you can step through the mozjs source.

Nice, didn't think of that.

> But the optimizations still make mozilla::HashBytes untraceable.

That's annoying.

> > Should this be reported as a bug against the package,
> 
> I honestly don't know.  I've had problems with Debian's spidermonkey
> package in the past.  Years ago, to compile on Debian, I had to pass a C
> preprocessor define, so that the layout of Spidermonkey structs was the
> same as the one Debian was using.  -DMOZILLA_1_8_BRANCH, I think it
> was.  I wouldn't be surprised if there was an issue in their package,
> but I really don't know for sure.
> I also tried compiling a "Hello world" spidermonkey application, and it
> segfaults in the same place.  Here it is:
> http://the-brannons.com/jshello.cpp

Ok. Is this the same as the smjs example (will look through later)?
If so, then that's definitely a debian bug and should probably be reported as
such, unless they provide a js-config script,
pkg-config .pc file or docs about this in their readme.
I'll look into this.
If any of these are provided I wonder if they provide the correct flags?

Cheers,
Adam.

Re: [Edbrowse-dev] 24

[Chris Brannon]

Adam Thompson <arthompson1990@gmail.com> writes:

> If so, then that's definitely a debian bug and should probably be reported as
> such, unless they provide a js-config script,
> pkg-config .pc file or docs about this in their readme.

They do provide a .pc file, but it is broken, as shown below:

Script started on Thu Feb  6 11:57:46 2014
chris@somehost:~$ g++ `pkg-config --cflags mozilla-js` jshello.cpp  `pkg-config --libs mozilla-js`
In file included from <command-line>:0:0:
/usr/include/stdc-predef.h:39:1: fatal error: /usr/include/mozjs/mozjs/js/RequiredDefines.h: No such file or directory
 #endif
 ^
compilation terminated.

So there's a possible bug in their package and a definite typo in their
.pc file.

-- Chris

Re: [Edbrowse-dev] 24

[Adam Thompson]

On Thu, Feb 06, 2014 at 12:05:50PM -0800, Chris Brannon wrote:
> Adam Thompson <arthompson1990@gmail.com> writes:
> 
> > If so, then that's definitely a debian bug and should probably be reported as
> > such, unless they provide a js-config script,
> > pkg-config .pc file or docs about this in their readme.
> 
> They do provide a .pc file, but it is broken, as shown below:
> 
> Script started on Thu Feb  6 11:57:46 2014
> chris@somehost:~$ g++ `pkg-config --cflags mozilla-js` jshello.cpp  `pkg-config --libs mozilla-js`
> In file included from <command-line>:0:0:
> /usr/include/stdc-predef.h:39:1: fatal error: /usr/include/mozjs/mozjs/js/RequiredDefines.h: No such file or directory
>  #endif
>  ^
> compilation terminated.
> 
> So there's a possible bug in their package and a definite typo in their
> .pc file.

Both count as bugs. I just tried including the mentioned header file using the
correct file and edbrowse still blows up in the same place I think.
At least it's better than the experimental mozjs26d package where the jsapi.h
is a broken symlink to something under /tmp!

I've tried asking the person at Debian about the compile flags but still
haven't heard anything. Could you please put together a couple of bug reports
or should I do it?

Cheers,
Adam.

Re: [Edbrowse-dev] 24

[Chris Brannon]

Adam Thompson <arthompson1990@gmail.com> writes:

> Could you please put together a couple of bug reports
> or should I do it?

Go for it, unless you're pressed for time.  I'm not really familiar with
their bug reporting procedures, as I'm not really a Debian user.  If
you're pressed for time, I'm willing to learn.

-- Chris

Re: [Edbrowse-dev] 24

[Adam Thompson]

On Thu, Feb 06, 2014 at 03:39:57PM -0800, Chris Brannon wrote:
> Adam Thompson <arthompson1990@gmail.com> writes:
> 
> > Could you please put together a couple of bug reports
> > or should I do it?
> 
> Go for it, unless you're pressed for time.  I'm not really familiar with
> their bug reporting procedures, as I'm not really a Debian user.  If
> you're pressed for time, I'm willing to learn.

I'll try and get this done this weekend.

Cheers,
Adam.