Created attachment 469292 [details] bzip2-compressed build.log Hi, While stabilizing bug #611134, emerging =dev-libs/glib-2.50.3-r1 with FEATURES=test fails to pass test run-assert-msg-test.sh. From tests/test-suite.log: ======================================= glib 2.50.3: tests/test-suite.log ======================================= # TOTAL: 28 # PASS: 27 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: run-assert-msg-test.sh ============================ Test failed: __glib_assert_msg does not have assertion message FAIL run-assert-msg-test.sh (exit status: 1) Nothing more, nothing less. No problem when tests are disabled. Anything I can try to help diagnose the problem? Thanks, Émeric
emerge --info output: Portage 2.3.3 (python 3.4.5-final-0, default/linux/ia64/13.0/desktop/gnome/systemd, gcc-4.9.4, glibc-2.23-r3, 4.9.6-gentoo-r1 ia64) ================================================================= System uname: Linux-4.9.6-gentoo-r1-ia64-Madison-with-gentoo-2.3 KiB Mem: 24981008 total, 20987520 free KiB Swap: 524272 total, 524272 free Timestamp of repository gentoo: Sun, 02 Apr 2017 18:15:01 +0000 sh bash 4.3_p48-r1 ld GNU ld (Gentoo 2.26.1 p1.0) 2.26.1 app-shells/bash: 4.3_p48-r1::gentoo dev-lang/perl: 5.22.3_rc4::gentoo dev-lang/python: 2.7.12::gentoo, 3.4.5::gentoo dev-util/cmake: 3.7.2::gentoo dev-util/pkgconfig: 0.28-r2::gentoo sys-apps/baselayout: 2.3::gentoo sys-apps/openrc: 0.23.2::gentoo sys-apps/sandbox: 2.10-r3::gentoo sys-devel/autoconf: 2.13::gentoo, 2.69::gentoo sys-devel/automake: 1.11.6-r1::gentoo, 1.15::gentoo sys-devel/binutils: 2.26.1::gentoo sys-devel/gcc: 4.5.4::gentoo, 4.9.4::gentoo sys-devel/gcc-config: 1.7.3::gentoo sys-devel/libtool: 2.4.6-r3::gentoo sys-devel/make: 4.2.1::gentoo sys-kernel/linux-headers: 4.4::gentoo (virtual/os-headers) sys-libs/glibc: 2.23-r3::gentoo Repositories: gentoo location: /usr/portage sync-type: rsync sync-uri: rsync://rsync.fr.gentoo.org/gentoo-portage priority: -1000 my_ebuilds location: /var/lib/layman/my_ebuilds masters: gentoo priority: 0 ACCEPT_KEYWORDS="ia64" ACCEPT_LICENSE="* -@EULA" CBUILD="ia64-unknown-linux-gnu" CFLAGS="-O2 -pipe" CHOST="ia64-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="ftp://mirrors.linuxant.fr/distfiles.gentoo.org/" LANG="fr_FR.utf8" LDFLAGS="-Wl,-O1" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git" PORTAGE_TMPDIR="/var/tmp" USE="X a52 aac acl acpi alsa berkdb branding bzip2 cairo cdda cdr cli colord cracklib crypt cups cxx dbus dri dts dvdr eds encode evo exif fam firefox flac fortran gdbm gif glamor gnome gnome-keyring gnome-online-accounts gpm gstreamer gtk ia64 iconv introspection ipv6 jpeg lcms ldap libnotify libsecret mad mng modules mp3 mp4 mpeg nautilus ncurses nls nptl ogg opengl openmp pam pango pcre pdf png policykit ppds pulseaudio qt3support qt4 readline sdl session spell ssl startup-notification svg systemd tcpd tiff tracker truetype udev udisks unicode upower usb vorbis wayland wxwidgets x264 xattr xcb xml xv xvid zlib" ALSA_CARDS="fm801" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="evdev" KERNEL="linux" L10N="fr" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="fr" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-6" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_4" RUBY_TARGETS="ruby21" USERLAND="GNU" VIDEO_CARDS="radeon fbdev" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CC, CPPFLAGS, CTARGET, CXX, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
Created attachment 469294 [details] environment
emerge -pqv output: [ebuild R ] dev-libs/glib-2.50.3-r1 USE="dbus (mime) {test*} xattr -debug (-fam) (-selinux) -static-libs (-systemtap) -utils" PYTHON_TARGETS="python2_7"
could use this: ======================================= glib 2.50.3: tests/test-suite.log =======================================
(In reply to Mart Raudsepp from comment #4) > could use this: > > ======================================= > glib 2.50.3: tests/test-suite.log > ======================================= Sorry Mart, I don't understand what you're expecting there ;-) tests/test-suite.log file? In this case, I've copied exactly its content in the bug description. As I said, "nothing more, nothing less": it's really all what's in tests/test-suite.log, I promise: ======================================= glib 2.50.3: tests/test-suite.log ======================================= # TOTAL: 28 # PASS: 27 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: run-assert-msg-test.sh ============================ Test failed: __glib_assert_msg does not have assertion message FAIL run-assert-msg-test.sh (exit status: 1) Émeric
I'm apparently blind, thanks.
Do you have gdb installed?
Basically the test is supposed to be only executing if you have gdb. And if you have gdb, then it will run a script with it on the compiled test: run set print elements 0 print (char*) __glib_assert_msg quit And then if it doesn't see some assertion string in there as message, it fails the test.
basically something in that check isn't working out for you on ia64; somehow different compilation, leaving out asserts, or they have a different thing somehow that the grep gives something slightly different, etc. I think you should be able to go to the tests directory and run ./run-assert-msg-test.sh manually there to check it out, potentially adding some echo's or whatnot in the script to figure out what exactly is different or not to its liking. Looks like the .sh script can take a -v argument to display the gdb parts stderr, in case that is revealing.
(In reply to Mart Raudsepp from comment #9) > basically something in that check isn't working out for you on ia64; somehow > different compilation, leaving out asserts, or they have a different thing > somehow that the grep gives something slightly different, etc. > I think you should be able to go to the tests directory and run > ./run-assert-msg-test.sh manually there to check it out, potentially adding > some echo's or whatnot in the script to figure out what exactly is different > or not to its liking. Looks like the .sh script can take a -v argument to > display the gdb parts stderr, in case that is revealing. OK, I'll have a look at this. Maybe GDB is simply failing because of bug #518130. Which is becoming problematic nowadays, as the only workaround for me was to rebuild my kernel with GCC 4.5.4, last GCC version that never had a problem with GDB. But two days ago, GCC 4.5.4 was masked: !!! The following installed packages are masked: - sys-devel/gcc-4.5.4::gentoo (masked by: package.mask) /usr/portage/profiles/package.mask: # Michał Górny <mgorny@gentoo.org>, Andreas K. Hüttel <dilfridge@gentoo.org>, # Matthias Maier <tamiko@gentoo.org> (21 May 2017) # Those old versions of GCC are no longer really supported and are not # suitable for use as a system-wide compiler. Using them can result # in build failures (and possible breakage) for many packages. # # If you still use one of these as your system compiler, please upgrade # and switch the compiler ASAP. If you need them for a specific (isolated) # use case, feel free to unmask them on your system. Of course, I can still unmask it locally, but this means that I'm going to a dead-end sooner or later... Émeric
removing blocking marker meanwhile then. Tests would pass if gdb wasn't present; if it is, it has to work for such basic things like that gdb batch script in that test, or glib tests will fail. I think that's fine and proper tbh
(In reply to Mart Raudsepp from comment #9) > basically something in that check isn't working out for you on ia64; somehow > different compilation, leaving out asserts, or they have a different thing > somehow that the grep gives something slightly different, etc. > I think you should be able to go to the tests directory and run > ./run-assert-msg-test.sh manually there to check it out, potentially adding > some echo's or whatnot in the script to figure out what exactly is different > or not to its liking. Looks like the .sh script can take a -v argument to > display the gdb parts stderr, in case that is revealing. So it's not a problem with gdb per se, I think. run-assert-msg-test.sh itself runs assert-msg-test script. More exactly: OUT=$(./assert-msg-test 2>&1) && fail "assert-msg-test should abort" echo "$OUT" | grep -q '^GLib:ERROR:.*assert-msg-test.c:.*:.*main.*: assertion failed: (42 < 0)' || \ fail "does not print assertion message" If I manually run ./assert-msg-test, I get: ** GLib:ERROR:/var/tmp/portage/dev-libs/glib-2.50.3-r1/work/glib-2.50.3/tests/assert-msg-test.c:5:main: assertion failed: (42 < 0) Abort whis is matching the regexp passed to grep: grep -q '^GLib:ERROR:.*assert-msg-test.c:.*:.*main.*: assertion failed: (42 < 0)' Now, rather than simply running assert-msg-test, I'm redirecting its output in a variable, as in the test script: OUT=$(./assert-msg-test 2>&1) If I echo $OUT, I'm getting this: assert-msg-test assert-msg-test.o asyncqueue-test asyncqueue-test.log asyncqueue-test.o asyncqueue-test.trs atomic-test atomic-test.log atomic-test.o atomic-test.trs bit-test bit-test.log bit-test.o bit-test.trs child-test child-test.log child-test.o child-test.trs collate.out completion-test completion-test.log completion-test.o completion-test.trs cxx-test cxx-test.log cxx-test.o cxx-test.trs datetime datetime.log datetime.o datetime.trs dirname-test dirname-test.log dirname-test.o dirname-test.trs env-test env-test.log env-test.o env-test.trs file-test file-test-get-contents file-test.log file-test.o file-test.trs gio-test gio-test.log gio-test.o gio-test.trs gobject iochannel-test iochannel-test.o iochannel-test-outfile libmoduletestplugin_a.la libmoduletestplugin_a.lo libmoduletestplugin_b.la libmoduletestplugin_b.lo mainloop-test mainloop-test.log mainloop-test.o mainloop-test.trs Makefile mapchild mapping-test mapping-test.log mapping-test.o mapping-test.trs maptest memchunks.o module-test module-test.o onceinit onceinit.log onceinit.o onceinit.trs qsort-test qsort-test.log qsort-test.o qsort-test.trs refcount relation-test relation-test.log relation-test.o relation-test.trs run-assert-msg-test.sh.log run-assert-msg-test.sh.trs run-collate-tests.sh.log run-collate-tests.sh.trs slice-color slice-color.o slice-concurrent slice-concurrent.log slice-concurrent.o slice-concurrent.trs slice-test slice-test.o slice-threadinit slice-threadinit.log slice-threadinit.o slice-threadinit.trs sources sources.log sources.o sources.trs spawn-test spawn-test.o testgdate testgdate.log testgdate.o testgdateparser testgdateparser.o testgdate.trs testglib testglib.o test-suite.log threadpool-test threadpool-test.log threadpool-test.o threadpool-test.trs thread-test thread-test.log thread-test.o thread-test.trs timeloop timeloop.log timeloop.o timeloop.trs type-test type-test.log type-test.o type-test.trs unicode-caseconv unicode-caseconv.log unicode-caseconv.o unicode-caseconv.trs unicode-collate unicode-collate.o unicode-encoding unicode-encoding.log unicode-encoding.o unicode-encoding.trs unicode-normalize unicode-normalize.o GLib:ERROR:/var/tmp/portage/dev-libs/glib-2.50.3-r1/work/glib-2.50.3/tests/assert-msg-test.c:5:main: assertion failed: (42 < 0) Yes, you read it correctly: the contents of the current directory (i.e. the one where I'm running assert-msg-test) have been prepended to the assert-msg-test output, in fact replacing the ** string that is normally printed before the GLib error message when I'm not redirecting to a variable. Of course, this output isn't matching the regexp passed to grep, hence the test failure. I don't understand what's going on. I've tried with different variable names, ensuring they were empty before running VAR=$(./assert-msg-test 2>&1): still the same strange output. As a final check, I've redirected the output of assert-msg-test in a file rather than a variable: ./assert-msg-test > out 2>&1 cat out gives the expected output: ** GLib:ERROR:/var/tmp/portage/dev-libs/glib-2.50.3-r1/work/glib-2.50.3/tests/assert-msg-test.c:5:main: assertion failed: (42 < 0) Émeric
Just try ./run-assert-msg-test.sh -v as I suggested in the end?
(In reply to Mart Raudsepp from comment #13) > Just try > ./run-assert-msg-test.sh -v > as I suggested in the end? Yes. Nothing fun except printing "Running assert-msg-test" as a header. Émeric
Without re-reading all the previous comment, I think I recall the problem was with grepping the output from gdb batch run, not the assert message you are quoting now. So it's about: OUT=$($LIBTOOL --mode=execute gdb --batch -x ${srcdir:-.}/assert-msg-test.gdb ./assert-msg-test 2> $error_out) || fail "failed to run gdb" not passing grep -q '^$1.*"GLib:ERROR:.*assert-msg-test.c:.*:.*main.*: assertion failed: (42 < 0)"' Not the assert message itself. The gdb batch file is running the test program and then printing out the __glib_assert_msg global/static variable that holds the last assert or some such; kind of like errno. And validating that it's correct in there as well, in addition to the assert message you see in the stderr. So if your gdb fails with commands or outputs something different: run set print elements 0 print (char*) __glib_assert_msg quit Then the test fails.
Well, compiling =dev-libs/glib-2.50.3-r1 with debug informations (i.e. passing -ggdb to CFLAGS/CXXFLAGS and splitdebug to FEATURES) makes it pass the test suite: longspeak ~ # FEATURES=test emerge -q --oneshot dev-libs/glib:2 >>> Verifying ebuild manifests >>> Emerging (1 of 1) dev-libs/glib-2.50.3-r1::gentoo >>> Installing (1 of 1) dev-libs/glib-2.50.3-r1::gentoo * Messages for package dev-libs/glib-2.50.3-r1: * Tests for search-utils have been skipped I've double-checked that "test" was really passed to FEATURES, alongside "splitdebug": longspeak ~ # equery uses dev-libs/glib [ Legend : U - final flag setting for installation] [ : I - package is installed with flag ] [ Colors : set, unset ] * Found these USE flags for dev-libs/glib-2.50.3-r1: U I + + dbus : Enable dependencies required by glib libraries using dbus service to manage settings saving - - debug : Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see https://wiki.gentoo.org/wiki/Pro ject:Quality_Assurance/Backtraces - + mime : Pull in shared MIME database that many glib-based applications require at runtime to detect or open files. Warning: do not disable this flag unless installing on a headless server. + + python_targets_python2_7 : Build with Python 2.7 - - static-libs : Build static versions of dynamic libraries as well - + test : Workaround to pull in packages needed to run with FEATURES=test. Portage-2.1.2 handles this internally, so don't set it in make.conf/package.use anymore - - utils : Install gtester-report utility to generate test report files for your software; build gresource utility with ELF support. + + xattr : Add support for extended attributes (filesystem-stored metadata) Manually running run-assert-msg-test.sh -v now gives: Running assert-msg-test Running gdb on assert-msg-test Failed to read a valid object file image from memory. ** GLib:ERROR:/var/tmp/portage/dev-libs/glib-2.50.3-r1/work/glib-2.50.3/tests/assert-msg-test.c:5:main: assertion failed: (42 < 0) Checking if assert message is in __glib_assert_msg All tests passed. Is it expected? Émeric
The gdb output supposedly is differing then without debug symbols too much on ia64, while not elsewhere?
(In reply to Mart Raudsepp from comment #17) > The gdb output supposedly is differing then without debug symbols too much > on ia64, while not elsewhere? I'm seeing the same failure on amd64 with dev-libs/glib-2.52.3 and gdb 7.12.1.
Does this work with 2.54.3-r5? It includes upstream fix for https://bugzilla.gnome.org/show_bug.cgi?id=782057
Assuming it may be fixed then. In any case, 2.60.6 is meson-based now and could use a new report with meson testlog.txt and such instead.
Yes, tests pass for me with glib 2.58.3 and glib 2.60.6.
Can't check if this one is really fixed as =dev-libs/glib-2.60.6 fails earlier on test gio/tests/test_resources (bug #699180).
