Date: Sun, 2 Oct 2011 23:01:57 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Baptiste Daroussin <bapt@freebsd.org> Cc: Doug Barton <dougb@freebsd.org>, office@freebsd.org, "freebsd-ports@FreeBSD.org" <freebsd-ports@freebsd.org> Subject: Re: Still can't build libreoffice Message-ID: <20111002200157.GM1511@deviant.kiev.zoral.com.ua> In-Reply-To: <20111002195436.GA19540@azathoth.lan> References: <4E8818EF.10204@FreeBSD.org> <20111002195436.GA19540@azathoth.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
--Acw39dIkjvUsIOtC
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Oct 02, 2011 at 09:54:36PM +0200, Baptiste Daroussin wrote:
> On Sun, Oct 02, 2011 at 12:55:27AM -0700, Doug Barton wrote:
> > I'm on 9-current r225756 amd64. Since the latest version of libreoffice
> > was committed I always get stuck with cppunittest pegging the cpu at
> > 100% and never completing. I've tried removing the port and letting
> > libreoffice reinstall it as a dependency, no luck.
> >=20
> > Here's where I'm getting stuck:
> >=20
> > ----------------------------------------------------------
> > - start unit test #1 on library ../../unxfbsd.pro/lib/libcppu_ifcontain=
er.so
> > ----------------------------------------------------------
> > : &&
> > LD_LIBRARY_PATH=3D/mnt/local2/tmp/home/ports/editors/libreoffice/work/l=
ibreoffice-bootstrap-3.4.3.2/clone/ure/cppuhelper/unxfbsd.pro/lib:/mnt/loca=
l2/tmp/home/ports/editors/libreoffice/work/libreoffice-bootstrap-3.4.3.2/so=
lver/340/unxfbsd.pro/lib${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
> >=20
> > /mnt/local2/tmp/home/ports/editors/libreoffice/work/libreoffice-bootstr=
ap-3.4.3.2/solver/340/unxfbsd.pro/bin/cppunit/cppunittester
> > ../../unxfbsd.pro/lib/libcppu_ifcontainer.so
> > OK (5)
> >=20
> > And ktrace'ing the process gets endless repetition of this:
> >=20
> > 46718 cppunittester CALL sigprocmask(SIG_BLOCK,0x80083f720,0x7fffffff=
8030)
> > 46718 cppunittester RET sigprocmask 0
> > 46718 cppunittester CALL sigprocmask(SIG_SETMASK,0x80083f734,0)
> > 46718 cppunittester RET sigprocmask 0
> > 46718 cppunittester CALL sigprocmask(SIG_BLOCK,0x80083f720,0x7fffffff=
8030)
> > 46718 cppunittester RET sigprocmask 0
> > 46718 cppunittester CALL sigprocmask(SIG_SETMASK,0x80083f734,0)
> > 46718 cppunittester RET sigprocmask 0
> > 46718 cppunittester CALL sigprocmask(SIG_BLOCK,0x80083f720,0x7fffffff=
81f0)
> > 46718 cppunittester RET sigprocmask 0
> > 46718 cppunittester CALL sigprocmask(SIG_SETMASK,0x80083f734,0)
> > 46718 cppunittester RET sigprocmask 0
> > 46718 cppunittester CALL sigprocmask(SIG_BLOCK,0x80083f720,0x7fffffff=
81f0)
> > 46718 cppunittester RET sigprocmask 0
> > 46718 cppunittester CALL sigprocmask(SIG_SETMASK,0x80083f734,0)
> > 46718 cppunittester RET sigprocmask 0
> >=20
> > Which leads me to believe it's stuck in a loop somewhere.
> >=20
> >=20
> > Any ideas?
> >=20
> > Doug
> >=20
>=20
> Now idea at all about that, currently you are the only reporting that to =
me,
> i'll check with some upstream devs, hope they will have more ideas that I=
do
The sigprocmask() syscalls could be issued from the rtld.
I think a drill-down is needed there. Ideally, the minimal C source
program that exhibit the problem is to be determined.
Meantime, if my guess is close to the right, you can compile
rtld/libc/libthr with the debugging information and attach gdb to the
looping process. Then, get several backtraces of the looping thread,
interleaved with "continue", to roughly determine the loop block.
--Acw39dIkjvUsIOtC
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)
iEYEARECAAYFAk6IwzUACgkQC3+MBN1Mb4jppgCgrmA9GyNKgD/8VCQPe6rY5Vvy
/NoAoJEsGm/q2/IfxtqNEL76PKvjmI5l
=9Oxe
-----END PGP SIGNATURE-----
--Acw39dIkjvUsIOtC--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111002200157.GM1511>