391953 - Firefox/SeaMonkey hangs since Cairo 1.5 landed on trunk

Status: RESOLVED FIXED

(Core :: General, defect)

Description

[Marco Perez [:mpk]]

Attachment: Console output from current Firefox trunk debug build on FreeBSD

Trunk builds for both Firefox and SeaMonkey with sources
checked out after "2007-08-02 07:03:00 UTC" tend to hang.
They work okay however when checked out at or before
"2007-08-02 06:53:00 UTC").
The hangs occur even when no profile is present and when
started with the command-line parameters "-safe-mode" or
"-ProfileManager".
When the browser tries to display dialog boxes, they are
displayed without any content and the browser starts to
max out the CPU. The same behaviour can be observed when
trying to load e.g. http://slashdot.org/ . About:blank or
http://www.mozilla.org/ don't seem to trigger the bug,
while simply selecting an entry from the Mozilla menu bar
does.
I don't know whether this information is useful, but when
I trigger the bug and generate a backtrace in gdb I get
the following:
#0  0x28c38497 in _umtx_op () from /lib/libc.so.6
#1  0x28b3d941 in pthread_cleanup_pop () from /usr/lib/libthr.so.2
#2  0x28b3ce7f in pthread_cond_destroy () from /usr/lib/libthr.so.2
#3  0x283b7672 in PR_WaitCondVar (cvar=0x95157c0, timeout=4294967295) at /work/mozilla/nsprpub/pr/src/pthreads/ptsynch.c:405
#4  0x283b7dd1 in PR_Wait (mon=0x9522000, timeout=4294967295) at /work/mozilla/nsprpub/pr/src/pthreads/ptsynch.c:584
#5  0x282ef654 in nsAutoMonitor::Wait (this=0xbf0f5e44, interval=4294967295) at nsAutoLock.h:321
#6  0x28322155 in nsEventQueue::GetEvent (this=0x951ef24, mayWait=1, result=0xbf0f5ed4) at /work/mozilla/xpcom/threads/nsEventQueue.cpp:85
#7  0x28324bc4 in nsThread::nsChainedEventQueue::GetEvent (this=0x951ef1c, mayWait=1, event=0xbf0f5ed4) at nsThread.h:112
#8  0x28324362 in nsThread::ProcessNextEvent (this=0x951ef00, mayWait=1, result=0xbf0f5f34) at /work/mozilla/xpcom/threads/nsThread.cpp:481
#9  0x282ade8f in NS_ProcessNextEvent_P (thread=0x951ef00, mayWait=1) at nsThreadUtils.cpp:227
#10 0x283236a0 in nsThread::ThreadFunc (arg=0x951ef00) at /work/mozilla/xpcom/threads/nsThread.cpp:254
#11 0x283be8f0 in _pt_root (arg=0x9522100) at /work/mozilla/nsprpub/pr/src/pthreads/ptthread.c:221
#12 0x28b36f67 in pthread_create () from /usr/lib/libthr.so.2
#13 0x00000000 in ?? ()

Adding Vlad to cc: list since he checked Cairo 1.5 in.
If there's something I can do to provide additional
information, please let me know. BTW, is this the right
component? I had to guess in order to be able to submit
this bug.

Comment 1

[Marco Perez [:mpk]]

The symptoms of this bug seem to be exactly the same as for
bug #392170. But this one emerged earlier and Windows
didn't seem to be affected. Unfortunately Mats' bandaid
patch (from bug #390898) doesn't seem to help with this
one.
I still suspect that I chose the wrong component when I
filed this bug... --> changing to General

Comment 2

[Marco Perez [:mpk]]

Adding the option "--with-system-cairo" didn't prevent my
builds from hanging. Unfortunately the linker runs out of
memory whenever I try to build debug-enabled builds with
symbols. So no full backtrace for now... :-(
Let's see if tuning my kernel and/or build parameters helps
with this last issue...

Comment 3

[Marco Perez [:mpk]]

This bug is fixed now. And it seems to be thanks to Mats'
fix for bug #378716. Builds with sources checked out from
"2007-08-31 07:00 UTC" still fail, while the sources from
"2007-08-31 08:00 UTC" result in working builds. Thanks a
lot. Marking FIXED.

Comment 4

[Mats Palmgren (inactive)]

(In reply to comment #2)
> Unfortunately the linker runs out of
> memory whenever I try to build debug-enabled builds with
> symbols. So no full backtrace for now... :-(

FWIW, I have vague memory that I needed run "ulimit" and set something
to "unlimited" when that happened to me a long time ago on FreeBSD...

Comment 5

[Marco Perez [:mpk]]

Mats, I was finally able to work around this issue by
adding the following lines to /boot/loader.conf (the
PC runs on 1GB of physical RAM):
kern.maxdsiz="1G"
kern.maxssiz="128M"
kern.dfldsiz="1G"

I still haven't much experience with either debugging
on FreeBSD or hacking on Mozilla (I am no programmer)
anyway, but in the last few months I've collected enough
bits and pieces to soon be able to start a page about
building and debugging Mozilla on FreeBSD at d.m.o.

Patches like the first one (WIP) attached to bug #352822
are invaluable when building on FreeBSD stable. Current
has its own set of issues afaict, but that will require
its own tracking bug. I still haven't spent much time
trying, but FreeBSD 7 seems to deliver some serious
performance boosts as compared to previous versions.