* [Edbrowse-dev] 24
@ 2014-02-06 2:24 Karl Dahlke
2014-02-06 4:35 ` Chris Brannon
0 siblings, 1 reply; 9+ messages in thread
From: Karl Dahlke @ 2014-02-06 2:24 UTC (permalink / raw)
To: Edbrowse-dev
> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Edbrowse-dev] 24 2014-02-06 2:24 [Edbrowse-dev] 24 Karl Dahlke @ 2014-02-06 4:35 ` Chris Brannon 2014-02-06 10:34 ` Adam Thompson 0 siblings, 1 reply; 9+ messages in thread From: Chris Brannon @ 2014-02-06 4:35 UTC (permalink / raw) To: Edbrowse-dev 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Edbrowse-dev] 24 2014-02-06 4:35 ` Chris Brannon @ 2014-02-06 10:34 ` Adam Thompson 2014-02-06 15:29 ` Chris Brannon 0 siblings, 1 reply; 9+ messages in thread From: Adam Thompson @ 2014-02-06 10:34 UTC (permalink / raw) To: Chris Brannon; +Cc: Edbrowse-dev 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Edbrowse-dev] 24 2014-02-06 10:34 ` Adam Thompson @ 2014-02-06 15:29 ` Chris Brannon 2014-02-06 18:03 ` Adam Thompson 0 siblings, 1 reply; 9+ messages in thread From: Chris Brannon @ 2014-02-06 15:29 UTC (permalink / raw) To: Edbrowse-dev 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Edbrowse-dev] 24 2014-02-06 15:29 ` Chris Brannon @ 2014-02-06 18:03 ` Adam Thompson 2014-02-06 20:05 ` Chris Brannon 0 siblings, 1 reply; 9+ messages in thread From: Adam Thompson @ 2014-02-06 18:03 UTC (permalink / raw) To: Chris Brannon; +Cc: Edbrowse-dev 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Edbrowse-dev] 24 2014-02-06 18:03 ` Adam Thompson @ 2014-02-06 20:05 ` Chris Brannon 2014-02-06 22:03 ` Adam Thompson 0 siblings, 1 reply; 9+ messages in thread From: Chris Brannon @ 2014-02-06 20:05 UTC (permalink / raw) To: Edbrowse-dev 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Edbrowse-dev] 24 2014-02-06 20:05 ` Chris Brannon @ 2014-02-06 22:03 ` Adam Thompson 2014-02-06 23:39 ` Chris Brannon 0 siblings, 1 reply; 9+ messages in thread From: Adam Thompson @ 2014-02-06 22:03 UTC (permalink / raw) To: Chris Brannon; +Cc: Edbrowse-dev 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Edbrowse-dev] 24 2014-02-06 22:03 ` Adam Thompson @ 2014-02-06 23:39 ` Chris Brannon 2014-02-07 8:10 ` Adam Thompson 0 siblings, 1 reply; 9+ messages in thread From: Chris Brannon @ 2014-02-06 23:39 UTC (permalink / raw) To: Edbrowse-dev 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Edbrowse-dev] 24 2014-02-06 23:39 ` Chris Brannon @ 2014-02-07 8:10 ` Adam Thompson 0 siblings, 0 replies; 9+ messages in thread From: Adam Thompson @ 2014-02-07 8:10 UTC (permalink / raw) To: Chris Brannon; +Cc: Edbrowse-dev 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2014-02-07 8:11 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-02-06 2:24 [Edbrowse-dev] 24 Karl Dahlke 2014-02-06 4:35 ` Chris Brannon 2014-02-06 10:34 ` Adam Thompson 2014-02-06 15:29 ` Chris Brannon 2014-02-06 18:03 ` Adam Thompson 2014-02-06 20:05 ` Chris Brannon 2014-02-06 22:03 ` Adam Thompson 2014-02-06 23:39 ` Chris Brannon 2014-02-07 8:10 ` Adam Thompson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).