In message <86li6woie6....@gly.ath.cx>, Joseph Mingrone writes: > Ted Faber <fa...@lunabase.org> writes: > > gcc46 gives me a compilation error: > > > > /usr/ports/www/firefox/work/mozilla-release/xpcom/io/nsMultiplexInputStream > .cpp: In member function 'virtual nsresult nsMultiplexInputStream::Seek(int32 > _t, int64_t)': > > /usr/ports/www/firefox/work/mozilla-release/xpcom/io/nsMultiplexInputStream > .cpp:532:86: error: no matching function for call to 'XPCOM_MIN(int64_t&, __g > nu_cxx::__enable_if<true, double>::__type)' > > /usr/ports/www/firefox/work/mozilla-release/xpcom/io/nsMultiplexInputStream > .cpp:532:86: note: candidate is: > > ../../dist/include/nsAlgorithm.h:34:1: note: template<class T> const > > T& XPCOM_MIN(const T&, const T&) > > I'm on 9.1-STABLE #0 r246915 and configured firefox as follows: > Options: > DBUS: off > DEBUG: off > GCONF: off > GIO: off > GNOMEUI: off > GNOMEVFS2: off > GSTREAMER: on > LIBPROXY: off > LOGGING: off > OPTIMIZED_CFLAGS: off > PGO: off > WEBRTC: off > ALSA: off > OSS: on > PULSEAUDIO: off
With the xpcom patch and r251047 applied to libc, no joy here. It segfaults in .cerror (same as Ted Faber's <fa...@lunabase.org> previous post to ports@). I heard from someone that it does work on HEAD. I haven't tried it yet (my laptop is quad boot. Trying it this week might be pushing it for me but I'll give it a try over the next couple of weeks. I did try FF 22 beta. It too segfaults. Running it on my server system downstairs with DISPLAY=laptop:0 works (using a virgin ~/.mozilla and a ~/.mozilla copied from my laptop). Thinking that it might be because I use a UNIX domain socket (DISPLAY=:0) and not an Internet socket (DISPLAY=localhost:0) I did try the latter. It still segfaulted. I think this may be a timing issue as my laptop is a dual core hyperthreaded Intel I3 (2.4 GHz) while my main server system is an AMD X2 4600 (dual core, no hyperthreading, also 2.4 GHz), not to mention latency imposed because of the gigabit wire rather than memory-to-memory communication. I did try it on 1.6 GHz Pentium M laptop (single core) and it too segfaulted. I think the network latency does alter the timing enough to allow it to work. (And no, using synchronous X calls does nothing to help.) I've yet to recompile with debug symbols as it fails due to memory exhaustion. Debug symbols would be able to pinpoint where it's failing. Having said that, having worked on numerous multi-threaded applications, strange things happen when locking is not just right. I think there may be a bug in FF or in our libthr that is tickled under the right circumstances such as we see here. Running it over the wire seems to slow it down enough to avoid the problem. Processor speed and number of processors doesn't seem to mitigate the resulting segfault though. Until someone can build with -g and get a meaningful backtrace I think this one will be a bear to find. -- Cheers, Cy Schubert <cy.schub...@komquats.com> FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
