NetBSD Problem Report #55283

From www@netbsd.org  Thu May 21 15:38:50 2020
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 8E9551A9227
	for <gnats-bugs@gnats.NetBSD.org>; Thu, 21 May 2020 15:38:50 +0000 (UTC)
Message-Id: <20200521153849.89C751A9228@mollari.NetBSD.org>
Date: Thu, 21 May 2020 15:38:49 +0000 (UTC)
From: romain@dolbeau.org
Reply-To: romain@dolbeau.org
To: gnats-bugs@NetBSD.org
Subject: Qt5 doesn't compile on sparc, seems to be a QtMutex problem
X-Send-Pr-Version: www-1.0

>Number:         55283
>Category:       pkg
>Synopsis:       Qt5 doesn't compile on sparc, seems to be a QtMutex problem
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu May 21 15:40:00 +0000 2020
>Originator:     Romain Dolbeau
>Release:        2020Q1 (also checked with 2107Q1)
>Organization:
>Environment:
NetBSD ss20.dolbeau.name 9.0 NetBSD 9.0 (GENERIC.MP) #0: Fri Feb 14 00:06:28 UTC 2020  mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/sparc/compile/GENERIC.MP sparc (true hardware)

and

NetBSD vmsparc.dolbeau.name 9.0 NetBSD 9.0 (GENERIC) #0: Fri Feb 14 00:06:28 UTC 2020  mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/sparc/compile/GENERIC sparc (qemu)

>Description:
Qt5 (specifically, qt5-qtbase in /usr/pkgsrc/x11) doesn't compile on sparc. Primary symptom is an apparent hang while generating files using 'uic', but it happens later with other qt-based commands (e.g. qdbusxml2cpp).

I originally discovered the problem with 2020Q1 (v 5.14.2) but also went back to 2017Q1 (v 5.5.1) in the hope it was a recent bug - but it isn't, v5.5.1 has the same issue (in fact some of the findings below are from v5.5.1).

It seems the issue lies with mutex/lock, and in particular recursive QtMutex. The neverending programs do a lot of atomic operations (__atomic_compare_exchange_4 in particular) when examined in GDB, with a backtrace going through QtMutex functions. I tried on real hardware (SS20 with dual SM61) to make sure it wasn't a Qemu artifact, same thing.

After poking around in the 'qdbusxml2cpp' case, I realized some mutex ended up in QBasicMutex::lockInternal, despite the fact they looked a lot like recursive mutexes. This can be confirmed by enabling asserts in the src/corelib/thread/qmutex.cpp, by e.g. adding:

#ifdef QT_NO_DEBUG
#warning "QT_NO_DEBUG enabled, disabling"
#undef QT_NO_DEBUG
#endif

at the beginning of the file. This causes the offending binaries to crash with a segmentation fault in a string function (!!), whose backtrace goes through the failed assert "Q_ASSERT(!isRecursive())". I tried added '-O0' to the compiler command line, didn't help.

Unfortunately, I have no idea how to fix this. It could be a bug in QtMutex, it could also be a bug in the toolchain as such things are probably quite sensitive to the behavior of atomic operations and pre-v9 sparc isn't very good on that front :-(

Anyway I figure I should document my findings here just in case...
>How-To-Repeat:
Try to build qt5-qtbase on NetBSD 9.0/sparc. It never ends, as some program (uic in src/widgets probably will be first) never finishes.
>Fix:
None, sorry.

Home	PR Database Search