GNOME Bugzilla – Bug 794647
test_non_utf8_printf: assertion failed
Last modified: 2018-05-24 20:19:30 UTC
Hello, I'm seeing an assertion failure when testing glib 2.56.0, built using MacPorts. I got the same results on macOS 10.12.6 x86_64 and Mac OS X 10.4.11 ppc. ok 30 /GDateTime/now PASS: gdatetime 30 /GDateTime/now ** GLib:ERROR:gdatetime.c:1442:test_non_utf8_printf: assertion failed (__p == ("10\346\234\210")): ("October" == "10\346\234\210") ok 31 /GDateTime/printf PASS: gdatetime 31 /GDateTime/printf ../../tap-test: line 5: 68215 Abort trap: 6 $1 -k --tap Bail out! GLib:ERROR:gdatetime.c:1442:test_non_utf8_printf: assertion failed (__p == ("10\346\234\210")): ("October" == "10\346\234\210") ERROR: gdatetime - Bail out! GLib:ERROR:gdatetime.c:1442:test_non_utf8_printf: assertion failed (__p == ("10\346\234\210")): ("October" == "10\346\234\210")
Also happens on Fedora with both Autotools and Meson.
Do you have the latest ja.po translation, and is ja.mo installed correctly and used by GLib? (i.e. if you run the test under `strace -e trace=file …`, is the right ja.mo file listed as being opened and used?) That test is supposed to run in the ja_JP.eucjp locale, and is only supposed to get as far as line 1442 if setting that locale succeeded. glibc obviously has the locale data for Japan available, so it’s likely that the lookup of translations is failing.
I don't know how to answer the questions--I have whatever ja.po is in glib 2.56.0, and whatever ja.mo was produced from it. There is no strace command on macOS. The failing test is the one for "%B". If translation lookup was failing, wouldn't the tests for "%a" and "%A" on the preceding lines have failed? If I comment out the failing "%B" test, many of the subsequent tests run fine.
(In reply to Ryan Schmidt from comment #3) > I don't know how to answer the questions--I have whatever ja.po is in glib > 2.56.0, and whatever ja.mo was produced from it. There is no strace command > on macOS. We kind of need strace to make sure that the right file is actually being loaded. Nirbheek may be able to answer the questions on Linux, if he can still reproduce the problem. How are you building and installing GLib? Is this an installed copy, or are you running it out of the builddir? If you’re running it out of the builddir, do you have G_TEST_BUILDDIR set? > The failing test is the one for "%B". If translation lookup was failing, > wouldn't the tests for "%a" and "%A" on the preceding lines have failed? Not if translations existed for the `%a` and `%A` strings (or they could be retrieved from glibc), but not for the `%B` string. I think I might know what the problem is, actually: if you’re running the tests out of the builddir, they will probably be using the *installed* ja.mo file, rather than the newly built one. If you’re running the tests manually or using autotools, this test isn’t being skipped correctly (as per bug #794180) because G_TEST_BUILDDIR won’t be set in the environment. If those assumptions are true, the fix should be to copy the AM_TESTS_ENVIRONMENT variable from tests/Makefile.am to glib/tests/Makefile.am (and make sure it’s there for the other */tests/*/Makefile.am files too). > If I comment out the failing "%B" test, many of the subsequent tests run > fine. OK.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/1357.