Another Firefox 21.0 crash

[Cy Schubert]

In message <86li6woie6.fsf at gly.ath.cx>, Joseph Mingrone writes:
> Ted Faber <faber at 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 <faber at 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.Schubert at komquats.com>
FreeBSD UNIX:  <cy at FreeBSD.org>   Web:  http://www.FreeBSD.org