7+ days of dogfood

Steve Kargl sgk at troutmask.apl.washington.edu
Sun Feb 10 00:07:29 UTC 2013

In a long thread started by Peter Wemm on developers@, he described
the move/upgrade of the FreeBSD.org cluster to using FreeBSD-10.  A
part of his description included the need to test top-of-tree under
actual real-world conditions.  In his words, FreeBSD should "eat its
own dogfood."  The new installation on FreeBSD.org, of course, would
test FreeBSD-10 under (heavy) server load. 

So, I decided to test FreeBSD-10 under a user desktop condition.  In
so doing, I upgraded the circa August 2012 FreeBSD-current that ran
on my Dell Latitude D530 (which ran rock-solid) to top-of-tree.  This
included re-installing all ports under the pkgng paradigm.

I can only describe this experience as slowly shoving an icepick into
my ear channel.

Firefox segfaults after ~10 seconds.  Chrome gets stuck in a uwait
state and never becomes responsive.  Libreoffice displays its splash
screen and immediately segfaults.  Xorg does not start because it
cannot load the xf86-video-driver (unless it is explicitly recompiled
with /usr/bin/gcc).  Once I got Xorg working, there were a few silent
reboots (ie., nothing in /var/log/message, no core file, etc).

I spent a few days trying to hunt down the issues.  I rebult libc, 
libthr, libc++, and libcxxrt with debugging symbols and and firefox
and chrome under gdb751.  Nothing too informative to learn:

gdb751 /usr/local/share/chromium/chrome
(try going to seattle-times.com and get stuck)
(gdb) bt
#0  0x4d0323ab in _umtx_op_err () from /lib/libthr.so.3
#1  0x4d0274da in _thr_umtx_timedwait_uint () from /lib/libthr.so.3
#2  0x4d02d76f in _thr_sleep () from /lib/libthr.so.3
#3  0x4d0304b0 in ?? () from /lib/libthr.so.3
#4  0x4d030705 in pthread_cond_timedwait () from /lib/libthr.so.3
#5  0x086e7578 in ?? ()
#6  0x086f8d1b in ?? ()
#7  0x086f91c9 in ?? ()
#8  0x086f0c06 in ?? ()
#9  0x4d0255e6 in ?? () from /lib/libthr.so.3
#10 0x00000000 in ?? ()

gdb751 /usr/local/bin/firefox
(gdb) run
Starting program: /usr/local/bin/firefox 
[New LWP 100227]
[New Thread 48501080 (LWP 100227)]
[New Thread 4ec11500 (LWP 100245 StreamTrans #3)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 48501080 (LWP 100227)]
0x48c03295 in ?? () from /usr/local/lib/firefox/libxul.so
(gdb) bt
#0  0x48c03295 in ?? () from /usr/local/lib/firefox/libxul.so
#1  0x48aaf4b0 in ?? () from /usr/local/lib/firefox/libxul.so
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Unfortunately, trying to build firefox with debugging leads
reveals a broken port and building chrome with debugging leads
to a "file system full" issue (because it is a laptop with only
limited disk space).

Given that I need the laptop for work next week, I decide to rebuild
everything again.  Only this time I used the following /etc/make.conf:




  FFLAGS = -O2 -pipe -march=native -mtune=native
  FFLAGS+= -funroll-loops -ftree-vectorize

  # added by use.perl 2013-02-07 20:58:29

I now have an almost functioning desktop environment on my laptop.
firefox, xorg, and chrome all work.  Sound has developed a pronounced
studder, that did not occur with the Aug 2012 freebsd-10.  Libreoffice
currently does not build, but that's not totally unexpected as compiling
libreoffice seems to be a hit-or-miss proposition. 

My conclusion:  on at least my not-so-new laptop, FreeBSD-10 can
be used in a desktop environment if one takes some care during the


More information about the freebsd-current mailing list