Bug#927914: gblic: deal with Japanese new era "令和 (Reiwa)"

[Hideki Yamane]

package: glibc
tags: l10n, patch

Hi,

 To deal with Japanese new era "令和 (Reiwa)" (from 1st May), please
 add attached patch that is taken from upstream(*)

 It should be applied to stretch as well.

 (*) 
https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=7423da211d1490d9fc76c2f0ce49e5dd90ea9bcc;hp=4aeff335ca19286ee2382d8eba794ae5fd49281a


-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp
>From 3a660291290fd6e65db1f17fbfff67fa4ef2bc99 Mon Sep 17 00:00:00 2001
From: Hideki Yamane 
Date: Thu, 25 Apr 2019 10:33:00 +0900
Subject: [PATCH] add localedata/locale-ja_JP-reiwa_era.diff

---
 .../localedata/locale-ja_JP-reiwa_era.diff| 30 +++
 debian/patches/series |  1 +
 2 files changed, 31 insertions(+)
 create mode 100644 debian/patches/localedata/locale-ja_JP-reiwa_era.diff

diff --git a/debian/patches/localedata/locale-ja_JP-reiwa_era.diff b/debian/patches/localedata/locale-ja_JP-reiwa_era.diff
new file mode 100644
index ..141ee8a4
--- /dev/null
+++ b/debian/patches/localedata/locale-ja_JP-reiwa_era.diff
@@ -0,0 +1,30 @@
+Index: glibc/NEWS
+===
+--- glibc.orig/NEWS
 glibc/NEWS
+@@ -7,6 +7,10 @@ using `glibc' in the "product" field.
+ 
+ Version 2.28.1
+ 
++Major new features:
++
++* The entry for the new Japanese era has been added for ja_JP locale.
++
+ Deprecated and removed features, and other changes affecting compatibility:
+ 
+ * For powercp64le ABI, Transactional Lock Elision is now enabled iff kernel
+Index: glibc/localedata/locales/ja_JP
+===
+--- glibc.orig/localedata/locales/ja_JP
 glibc/localedata/locales/ja_JP
+@@ -14946,7 +14946,9 @@ am_pm	"";""
+ 
+ t_fmt_ampm "%p%I%M%S"
+ 
+-era	"+:2:1990//01//01:+*::%EC%Ey";/
++era	"+:2:2020//01//01:+*::%EC%Ey";/
++	"+:1:2019//05//01:2019//12//31::%EC";/
++	"+:2:1990//01//01:2019//04//30::%EC%Ey";/
+ 	"+:1:1989//01//08:1989//12//31::%EC";/
+ 	"+:2:1927//01//01:1989//01//07::%EC%Ey";/
+ 	"+:1:1926//12//25:1926//12//31::%EC";/
diff --git a/debian/patches/series b/debian/patches/series
index 461d8245..d75630cb 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -20,6 +20,7 @@ localedata/submitted-en_AU-date_fmt.diff
 localedata/submitted-es_MX-decimal_point.diff
 localedata/submitted-it_IT-thousands_sep.diff
 localedata/git-en_US-date_fmt.diff
+localedata/locale-ja_JP-reiwa_era.diff
 
 alpha/local-gcc4.1.diff
 alpha/submitted-dl-support.diff
-- 
2.20.1

Processed: your mail

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> retitle 927914 glibc: deal with Japanese new era "令和 (Reiwa)"
Bug #927914 [glibc] gblic: deal with Japanese new era "令和 (Reiwa)"
Changed Bug title to 'glibc: deal with Japanese new era "令和 (Reiwa)"' from 
'gblic: deal with Japanese new era "令和 (Reiwa)"'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
927914: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927914
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Zaprojektuję i wykonam dla Ciebie Stronę lub Sklep WWW.

[Creative Team | Strony,Sklepy WWW]

Dzień dobry,



widoczność w sieci jest nieodzownym elementem każdego biznesu.



Mamy świadomość, jak ważna jest* Strona i Sklep internetowy* przy prowadzeniu 
własnej firmy.



Z nadzieją, na możliwość przedstawienia Państwu naszej propozycji na ten temat, 
prosimy o przesłanie wiadomości zwrotnej: *TAK*. 



Creative Team | Strony, Sklepy Online

Processed (with 1 error): xend opcode in libpthread on non hle cpu

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 880659 libc6 2.24-11+deb9
Bug #880659 [stunnel4] [stunnel4] random segfaults in libcrypto.so.1.1 / 
libpthread-2.24.so
Bug reassigned from package 'stunnel4' to 'libc6'.
No longer marked as found in versions stunnel4/3:5.39-2.
Ignoring request to alter fixed versions of bug #880659 to the same values 
previously set
Bug #880659 [libc6] [stunnel4] random segfaults in libcrypto.so.1.1 / 
libpthread-2.24.so
There is no source info for the package 'libc6' at version '2.24-11+deb9' with 
architecture ''
Unable to make a source version for version '2.24-11+deb9'
Marked as found in versions 2.24-11+deb9.
> retitle 880659 sigill - xend opcode in libpthread on non hle/tsx cpu
Bug #880659 [libc6] [stunnel4] random segfaults in libcrypto.so.1.1 / 
libpthread-2.24.so
Changed Bug title to 'sigill - xend opcode in libpthread on non hle/tsx cpu' 
from '[stunnel4] random segfaults in libcrypto.so.1.1 / libpthread-2.24.so'.
> end
Unknown command or malformed arguments to command.
>
End of message, stopping processing here.

Please contact me if you need assistance.
-- 
880659: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880659
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: Re: [stunnel4] still random segfaults - gdb backtrace

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 stunnel4
Bug #880659 [libc6] sigill - xend opcode in libpthread on non hle/tsx cpu
Bug reassigned from package 'libc6' to 'stunnel4'.
No longer marked as found in versions 2.24-11+deb9.
Ignoring request to alter fixed versions of bug #880659 to the same values 
previously set
> retitle -1 stunnel4 calls pthread_rwlock_unlock on an rwlock which is not 
> locked
Bug #880659 [stunnel4] sigill - xend opcode in libpthread on non hle/tsx cpu
Changed Bug title to 'stunnel4 calls pthread_rwlock_unlock on an rwlock which 
is not locked' from 'sigill - xend opcode in libpthread on non hle/tsx cpu'.

-- 
880659: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880659
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#880659: [stunnel4] still random segfaults - gdb backtrace

[Aurelien Jarno]

control: reassign -1 stunnel4
control: retitle -1 stunnel4 calls pthread_rwlock_unlock on an rwlock which is 
not locked

Hi,

On 2019-04-21 16:26, Florian Lohoff wrote:
> 
> Hi,
> after installing corekeeper i got a coredump of the crashing stunnel.
> Installing some dbgsym packages i got this backtrace.
> 
> It seems the bug could be reassigned to glibc as it creashes
> in thread unlocking.
> 
> Its pretty interesting. It crashes in the "xend" instruction with
> is an opcode of the transactional memory feature. From the CPU type

Correct.

> it should be supported but concerning the Intel errata it might
> be disabled by microcode. Its not advertised as available in
> the cpuinfo - Should be flag "hle"
> 
> root@pax:/var/crash/0# lscpu
> Architecture:  x86_64
> CPU op-mode(s):32-bit, 64-bit
> Byte Order:Little Endian
> CPU(s):8
> On-line CPU(s) list:   0-7
> Thread(s) per core:2
> Core(s) per socket:4
> Socket(s): 1
> NUMA node(s):  1
> Vendor ID: GenuineIntel
> CPU family:6
> Model: 60
> Model name:Intel(R) Xeon(R) CPU E3-1270 v3 @ 3.50GHz
> Stepping:  3
> CPU MHz:   3699.951
> CPU max MHz:   3900.
> CPU min MHz:   800.
> BogoMIPS:  6983.94
> Virtualization:VT-x
> L1d cache: 32K
> L1i cache: 32K
> L2 cache:  256K
> L3 cache:  8192K
> NUMA node0 CPU(s): 0-7
> Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx 
> pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology 
> nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 
> ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt 
> tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm epb invpcid_single 
> ssbd ibrs ibpb stibp kaiser tpr_shadow vnmi flexpriority ept vpid fsgsbase 
> tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt dtherm ida arat pln pts 
> flush_l1d

This is correct your CPU doesn't support hardware lock elision, and
anyway hardware lock elision is disabled by default since glibc 2.24-9.

> [ snip ]

> root@pax:/var/crash/0# gdb -c 15*core /usr/bin/stunnel4
> GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
> Copyright (C) 2016 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from /usr/bin/stunnel4...Reading symbols from 
> /usr/lib/debug/.build-id/bb/b0710645254c912da337f32e7a2d40cd849ec3.debug...done.
> done.
> [New LWP 15247]
> [New LWP 15244]
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Core was generated by `/usr/bin/stunnel4 /etc/stunnel/stunnel-suucp.conf'.
> Program terminated with signal SIGILL, Illegal instruction.
> #0  0x7f51f7858c43 in _xend () at pthread_rwlock_unlock.c:38
> 38pthread_rwlock_unlock.c: No such file or directory.
> [Current thread is 1 (Thread 0x7f51f64ad700 (LWP 15247))]
> (gdb) info thread
>   Id   Target Id Frame 
> * 1Thread 0x7f51f64ad700 (LWP 15247) 0x7f51f7858c43 in _xend () at 
> pthread_rwlock_unlock.c:38
>   2Thread 0x7f51f8b13880 (LWP 15244) 0x7f51f785856f in 
> __GI___pthread_rwlock_wrlock (rwlock=0x5607e3c25070) at 
> pthread_rwlock_wrlock.c:107
> (gdb) bt
> #0  0x7f51f7858c43 in _xend () at pthread_rwlock_unlock.c:38
> #1  __GI___pthread_rwlock_unlock (rwlock=0x5607e3c68ce0) at 
> pthread_rwlock_unlock.c:38
> #2  0x7f51f8453f09 in CRYPTO_THREAD_unlock (lock=) at 
> ../crypto/threads_pthread.c:79
> #3  0x7f51f8422c9d in rand_bytes (buf=0x7f51f0006ec0 
> "\031e\342\244\035O2\226\235p", num=0, pseudo=0) at 
> ../crypto/rand/md_rand.c:498
> #4  0x7f51f835b551 in bnrand (pseudorand=0, rnd=0x7f51f0002a10, 
> bits=2047, top=, bottom=) at 
> ../crypto/bn/bn_rand.c:46

The crash happens there because pthread_rwlock_unlock is called on an
rwlock which is not locked. This is an undefined behaviour, so calling
xend is perfectly fine here even if the CPU doesn't support it.

The problem is at the application level, I am therefore reassigning the
bug back to stunnel4.

Regards,
Aurelien

-- 
Aurelien Jarno