In the build environment of GNU Guix (chroot with only the necessary dependencies installed), "make check" on i686-linux systems often fails with the following error message: ERROR:test-common.c:199:test_types_language: assertion failed: (en == hb_language_from_string ("Enx", 2)) /...-bash-4.2/bin/bash: line 5: 6305 Aborted MALLOC_CHECK_=2 MALLOC_PERTURB_=$((${RANDOM:-256} % 256)) G_DEBUG=gc-friendly G_SLICE=always-malloc srcdir=. ${dir}$tst FAIL: test-common For a complete build log, see http://hydra.gnu.org/build/19494/nixlog/1 The failure is not deterministically reproducible, from time to time, "make check" does succeed. On x86_64-linux, there is no problem. The problem is present in at least harfbuzz 0.9.19 and 0.9.20. As dependencies of the build, we use cairo 1.12.16 icu4c 50.1.1 python 2.7.5 or 3.3.2 The compiler is gcc-4.7.3, the C library glibc-2.17. Andreas
I have absolutely no idea how that test can fail.
I printed out the values (as type %p, since both are pointers to a struct) that make the assertion fail: en is 0x8796188 hb_language_from_string ("Enx", 2) is 0x87961a8 The values differ with each run, of course, and sometimes (about one out of three times) are equal. When printing out the string content of the expressions, the first one is always "en"; the second one usually has three letters, such as "ena", "enu", "env", "enw", "enx". Andreas
Humm. Can you dig into hb-common.cc and dig into hb_language_from_string? In fact, we should never see three letters when you print the result. The only way I can think of that happening is that the memcpy() call there is misbehaving. Not sure how that can happen.
Oh. Wait...
I believe I fixed it in master: commit 48360ec03b225dfec5f90bc5cb93122203d2dd6b Author: Behdad Esfahbod <behdad@behdad.org> Date: Thu Sep 26 16:48:42 2013 -0400 Bug 68990 - test-common fails on i686-linux Fix use-after-end-of-scope. diff --git a/src/hb-common.cc b/src/hb-common.cc index 88f7ed1..cf24660 100644 --- a/src/hb-common.cc +++ b/src/hb-common.cc @@ -292,11 +292,13 @@ retry: hb_language_t hb_language_from_string (const char *str, int len) { + char strbuf[64]; + if (!str || !len || !*str) return HB_LANGUAGE_INVALID; - if (len >= 0) { - char strbuf[64]; + if (len >= 0) + { len = MIN (len, (int) sizeof (strbuf) - 1); str = (char *) memcpy (strbuf, str, len); strbuf[len] = '\0'; Please reopen if not fixed.
Indeed, it seems to work well in 0.9.22. Thanks!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.