lib/locale.t: Test failures and segfaulting on FreeBSD-11 and -12 #15681
Comments
From @jkeenanThis is a bug report for perl from jkeenan@cpan.org, lib/locale.t: Test failures and segfaulting on FreeBSD-11 and -12 Up to August of this year we had not been receiving any smoke-test In October FreeBSD designated version 11.0 as RELEASE and I set up a VM FreeBSD-11: http://perl5.test-smoke.org/report/50816 The source code which leads to these failures was committed to blead in The segfault typically happens after test 380 in lib/locale.t. On Karl, Dan and I have been discussing these failures off-list. Now that origin/smoke-me/khw-locale ... that we are currently testing. Results are promising. Note: The 'perl -V' output included is that of a build of blead on Thank you very much. Flags: Summary of my perl5 (revision 5 version 25 subversion 7) configuration: Characteristics of this binary (from libperl): |
From @dcollinsnAttached are the results of running this test against smoke-me/khw-locale under ASAN, first using a "normal" config, and then disabling HAS_STRXFRM in config.h and building again. Also attached is a diff of some instrumentation that I added to see when strxfrm() is being called, and the results of that. It is the first call with locale zh_CN.GB18030, but otherwise is unremarkable. -- |
From @dcollinsn[dcollins@nightshade-freebsd12 /usr/home/dcollins/perl]$ ./perl -Ilib -V Characteristics of this binary (from libperl): ok 382 skipped: testing of locale 'ja_JP.eucJP' is skipped: Locale 'ja_JP.eucJP' may not work well. Some characters in it are not recognized by Perl. ok 383 skipped: testing of locale 'ko_KR.CP949' is skipped: Locale 'ko_KR.CP949' may not work well. Some characters in it are not recognized by Perl. ok 384 skipped: testing of locale 'ko_KR.eucKR' is skipped: Locale 'ko_KR.eucKR' may not work well. Some characters in it are not recognized by Perl. ok 385 skipped: testing of locale 'zh_CN.GB18030' is skipped: Locale 'zh_CN.GB18030' may not work well. Some characters in it are not recognized by Perl. ok 386 skipped: testing of locale 'zh_CN.GB2312' is skipped: Locale 'zh_CN.GB2312' may not work well. Some characters in it are not recognized by Perl. ok 387 skipped: testing of locale 'zh_CN.GBK' is skipped: Locale 'zh_CN.GBK' may not work well. Some characters in it are not recognized by Perl. ok 388 skipped: testing of locale 'zh_CN.eucCN' is skipped: Locale 'zh_CN.eucCN' may not work well. Some characters in it are not recognized by Perl. ok 389 skipped: testing of locale 'zh_TW.Big5' is skipped: Locale 'zh_TW.Big5' may not work well. Some characters in it are not recognized by Perl. ok 390 Verify that /[[:upper:]]/ matches all alpha X for which uc(X) == X and lc(X) != X |
From @dcollinsn[dcollins@nightshade-freebsd12 /usr/home/dcollins/perl]$ ./perl -Ilib -V Characteristics of this binary (from libperl):
|
From [Unknown Contact. See original ticket]Attached are the results of running this test against smoke-me/khw-locale under ASAN, first using a "normal" config, and then disabling HAS_STRXFRM in config.h and building again. Also attached is a diff of some instrumentation that I added to see when strxfrm() is being called, and the results of that. It is the first call with locale zh_CN.GB18030, but otherwise is unremarkable. -- |
From @dcollinsnAnd the attached is a successful attempt to reproduce the failure in pure C code. If someone can confirm that the attached code should /not/ be crashing, we can submit the bug report to upstream. Note that the attached does not actually segfault - but ASAN sees the bug anyway. I'm not sure if this is the access that is actually segfaulting - I'd have to rebuild perl without ASAN to find out - but I bet it's related. The segfault was originally with the locale 'ja_JP.eucJP', which I think is being skipped now? -- |
From @dcollinsn[dcollins@nightshade-freebsd12 /usr/home/dcollins/perl]$ cat localetest.c int main() { buffer = (char*) malloc(1024*sizeof(char)); strxfrm(buffer, "ABCDEFGHIJLKMnopqrstuvwxyz", 255); locale = setlocale(LC_ALL, "zh_CN.GB18030"); strxfrm(buffer, "ABCDEFGHIJLKMnopqrstuvwxyz", 255);
|
From [Unknown Contact. See original ticket]And the attached is a successful attempt to reproduce the failure in pure C code. If someone can confirm that the attached code should /not/ be crashing, we can submit the bug report to upstream. Note that the attached does not actually segfault - but ASAN sees the bug anyway. I'm not sure if this is the access that is actually segfaulting - I'd have to rebuild perl without ASAN to find out - but I bet it's related. The segfault was originally with the locale 'ja_JP.eucJP', which I think is being skipped now? -- |
|
@jkeenan - Status changed from 'new' to 'open' |
From @khwilliamsonOn 10/24/2016 01:37 PM, Dan Collins via RT wrote:
My reading of Wikipedia on locale zh_CN.GB18030 is that it should not It also turns out that the strlcpy() on these systems is broken. This I'll go into some background. lib/locale.t is dual-purposed. It checks Perl only supports single byte locales, except for UTF-8 ones. It is The locales that are crashing on freebsd are multi-byte ones, which are locale.t runs a bunch of taint tests. Then there is a pause if you're So, where are we? strlcpy is broken. Our Configure could test for that. I have no strxfrm is broken at least on some multi-byte locales. There is no There are still some collation issues in UTF-8 locales on these systems, |
From @jkeenanOn Mon Oct 24 05:16:14 2016, jkeen@verizon.net wrote:
Status of lib/locale.t on FreeBSD-11 Oct 26 2016 Branch: smoke-me/khw-locale Commit: 79dfed8 lib/locale.t no longer crashes. When run individually via: cd t; ./perl harness -v ../lib/locale.t; cd - ... the first time there was a visible pause of multiple seconds after test 380. There was another, shorter, visible pause after test 389. But the test resumes and completes with 4 failures in tests 426 through 429. In a 'script' session, I then reconfigured and rebuilt for debugging: sh ./Configure -des -Dusedevel -Duseithreads -DDEBUGGING I re-ran the test: PERL_DEBUG_FULL_TEST=2 ./perl -Ilib -DLv -T lib/locale.t 2>&1 This time I did not see visible pauses. As before, the test completed without crashing. Typescript is large; available on request; will be sent to Karl and Dan directly. I then manually ran the file from the command-line with both: cd t; ./perl harness -v ../lib/locale.t; cd - # 4.88 real 4.76 user 0.11 sys ./perl -Ilib -T lib/locale.t # 4.82 real 4.74 user 0.07 sys Running with 'harness', I observed a visible pause at test 389, though shorter than previously. I did not observe a pause at test 389. I then got curious and grepped the typescript for locale.c. On the basis of the debugging output I saw there, I went into hints/freebsd.sh and added: d_strlcpy='undef' I reconfigured and rebuilt and reran the test. However, I got all the same debugging warnings. Thank you very much. -- |
From @khwilliamsonOn Wed Oct 26 04:27:27 2016, jkeenan wrote:
I have pushed to blead fixes that prevent the segfaults, particularly 0d94136. The segfaults are a bug in these OS versions. What the commits do is to not test locales that can be determined to be incompatible with Perl. Otherwise, every locale on the machine is tested. Someone may try to switch into one of these locales in a Perl program, and they could get segfaults. One solution would be for perl to refuse to switch to a locale it can determine is incompatible, but I'd rather not do that because some cases are complicated to handle, and this is clearly an OS bug that we haven't found elsewhere, and the docs say that these locales are problematic. The bug should be reported upstream to the vendor. Dan already may have done that. The remaining failures in the test are from the same underlying function that segfaults. We can report these upstream as well. I now have access to a failing system, and the strlcpy() problem is no longer manifesting. I don't understand why, and would rather not spend the tuits to figure it out. I think we should drop that from consideration unless it shows up again. As I explained in an earlier post, the pause after test 380 is while the test file is scanning the system to find and do sanity validation on all the locales on it. The second pause is because it tests each sane locale for problems, but doesn't print anything until it has created a consolidated report. |
From @jkeenanOn Wed Oct 26 12:00:09 2016, khw wrote:
Karl, thanks for all the time you've been putting in on this. The good news is that blead is now completing all its tests on FreeBSD-11.0 without segfaulting. There are failures in lib/locale.t, as you anticipated. I am generating smoke-tests now which should be available at perl5.test-smoke.org in a couple of hours. The bad news is that we have regressions (or, at least, test failures) in lib/locale.t on FreeBSD-10.3. I have run that program in debugging mode and, since the output is large, will email you and Dan that output. Thank you very much. -- |
From @jkeenanOn Wed Oct 26 13:46:24 2016, jkeenan wrote:
http://perl5.test-smoke.org/report/50912
http://perl5.test-smoke.org/report/50927
-- |
From @jkeenanOn Wed Oct 26 18:23:46 2016, jkeenan wrote:
It appears that we are now getting similar failures in lib/locale.t on OpenBSD - 6.0. See: http://perl5.test-smoke.org/report/50945 Thank you very much. -- |
From @jhiI am also getting a failure from locale.t in my private OpenBSD build. My NetBSD is a bit hosed at the moment, but I am guessing if I could get a build going, it would fail similarly. Furthermore, also both my Solaris builds (sparc and x86) fail on that test. Here's an idea: given that the locale.t does a task that is somewhat different than any other test in our test suite, that is, extensively test a system-provided database for validity -- should Perl really be doing that? Is it our job? Perl's responsibility? I do understand the original intent (I was the one who started cross-testing whether the system locales work with Perl, especially when we started doing UTF-8), but I am starting to think that this is not our problem. Yes, Perl may work wrong, or even crash, sometimes not even in Perl. But again, is this our problem? It is nice to be able to find these problems, and possibly report that upstream, but... as Karl points out, especially problematic are non-UTF8-locales, since they may require using system interfaces Perl doesn't know about and never will want to. Maybe the locale.t should be converted into a stand-alone utility that people may run to test their locales, after the fact. This would make more sense also because people may install (or upgrade, or uninstall) locales outside of their Perl build. |
From andrew@cpan.orgThe locale.t tests fail on OpenBSD because there is currently no support for LC_COLLATE. http://marc.info/?l=openbsd-misc&m=144698615023532&w=2 http://man.openbsd.org/setlocale Somewhat related, OpenBSD now has /usr/bin/locale, although that just means the logic here doesn't get used. https://perl5.git.perl.org/perl.git/blob/HEAD:/t/loc_tools.pl#l325 |
From @khwilliamsonOn Sun, 20 Nov 2016 14:34:15 -0800, andrew@cpan.org wrote:
It would be helpful if you, or anyone who has access to an OpenBSD could run the following test on a DEBUGGING build: cd t and capture the output and send it to me.
Right, so it isn't something that needs to be changed. The current code DTRT for old and new OPENBSD -- |
From @khwilliamsonOn 11/27/2016 08:18 AM, Karl Williamson via RT wrote:
But do it on the branch smoke-me/khw-locale, which has a fix in it.
|
From @jkeenanOn Thu, 27 Oct 2016 01:23:46 GMT, jkeenan wrote:
Successful smoke test reports: freebsd 10.3-RELEASE: http://perl5.test-smoke.org/report/52031 -- |
From @khwilliamsonOn Sat, 29 Oct 2016 10:39:41 -0700, jhi wrote:
I'm not ready to throw in the towel on this yet. It turns out that, contrary to my expectations, there was an additional bug in perl that showed up only on UTF-8 locales on ASCII platforms where a control above the ASCII range collated earlier than all ASCII-range locales. This was happening on *BSD platforms, but not Linux or most others. So these oddball locale definitions serve a useful purpose in finding edge-case bugs. perllocale has instructions for using lib/locale.t stand-alone to discover problems with locales. Debugging this also showed me a defect in a Hindi ISCII locale on FREEBSD, which was reported to the vendor, and I'm told is being fixed. -- |
From @khwilliamsonI'm resolving this ticket, as commit afc4976 appears to have fixed all issues mentioned in it. This was a bug introduced in the 5.25 series, so I'm resolving the ticket rather than marking it as pending release. The changes that added this bug did fix long-standing issues with collating embedded NULs, so that is still pending release of 5.26 |
|
@khwilliamson - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#129953 (status was 'resolved')
Searchable as RT129953$
The text was updated successfully, but these errors were encountered: