Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#45602 - [tcsh] 6.19.00-1 is broken
Attached to Project:
Community Packages
Opened by Bernard Michaud (polaris6262) - Thursday, 09 July 2015, 20:38 GMT
Last edited by Lukas Fleischer (lfleischer) - Friday, 10 July 2015, 08:08 GMT
Opened by Bernard Michaud (polaris6262) - Thursday, 09 July 2015, 20:38 GMT
Last edited by Lukas Fleischer (lfleischer) - Friday, 10 July 2015, 08:08 GMT
|
DetailsDescription:
The tcsh-6.19.00-1 shell just hangs and has to be interrupted. Even a simple --version invocation hangs. Additional info: * package version(s) 6.19.00-1 * config and/or log files etc. Steps to reproduce: |
This task depends upon
Closed by Lukas Fleischer (lfleischer)
Friday, 10 July 2015, 08:08 GMT
Reason for closing: Fixed
Additional comments about closing: Fixed in 6.19.00-2.
Friday, 10 July 2015, 08:08 GMT
Reason for closing: Fixed
Additional comments about closing: Fixed in 6.19.00-2.
[pid 595] <... sbrk resumed> ) = 0x8877000
[pid 595] <... setlocale resumed> ) = "en_US.UTF-8"
[pid 595] setlocale(LC_CTYPE, "") = "en_US.UTF-8"
[pid 595] mbtowc(0xbfe800a8, 0xbfe80d7a, 16, 0x8876008
and then the process uses 100% CPU.
gdb says:
#0 0x080856d5 in calloc ()
#1 0xb7e0bc0c in __wcsmbs_load_conv () from /usr/lib/libc.so.6
#2 0xb7dfe8c7 in mbrtowc () from /usr/lib/libc.so.6
#3 0xb7d9a14a in mbtowc () from /usr/lib/libc.so.6
#4 0x0808c649 in ?? ()
#5 0x0808c6d8 in ?? ()
#6 0x0808c74c in ?? ()
#7 0x0808cab4 in ?? ()
#8 0x0804a859 in ?? ()
#9 0xb7d83637 in __libc_start_main () from /usr/lib/libc.so.6
#10 0x0804c261 in ?? ()
In glibc in wcsmbs/wcsmbsload.c I see:
struct gconv_fcts *new_fcts;
new_fcts = calloc (1, sizeof *new_fcts);
Unless this structure is really big, why should this take forever?
In gdb I see:
#0 calloc (i=16, j=1) at tc.alloc.c:348
#1 0xb7e0bc0c in __wcsmbs_load_conv () from /usr/lib/libc.so.6
#2 0xb7dfe8c7 in mbrtowc () from /usr/lib/libc.so.6
#3 0xb7d9a14a in mbtowc () from /usr/lib/libc.so.6
#4 0x0808c649 in rt_mbtowc (
pwc=0xbffff958 L"\xbffffb68\x26304500t\xbffffc24\x80cac08\x808cab4\xbffffb68\xb7ff0940\xb7d8cdd9\xbffffc14\002\x80c03bc\xbffffb68\x804a859\xbffffc20\x808fb3b\xb7fe4a19\006\xbffffa18\xbffffa1c\xb7fffbe8\xb7fe4dd8", s=0xbffffd68 "XDG_VTNR=7", n=16) at tc.str.c:123
#5 0x0808c6d8 in one_mbtowc (
pwc=0xbffff958 L"\xbffffb68\x26304500t\xbffffc24\x80cac08\x808cab4\xbffffb68\xb7ff0940\xb7d8cdd9\xbffffc14\002\x80c03bc\xbffffb68\x804a859\xbffffc20\x808fb3b\xb7fe4a19\006\xbffffa18\xbffffa1c\xb7fffbe8\xb7fe4dd8", s=0xbffffd68 "XDG_VTNR=7", n=16) at tc.str.c:54
#6 0x0808c74c in str2short (src=src@entry=0xbffffd68 "XDG_VTNR=7") at tc.str.c:203
#7 0x0808cab4 in str2short (src=<optimized out>) at tc.str.c:166
#8 blk2short (src=<optimized out>) at tc.str.c:167
#9 0x0804a859 in main (argc=2, argv=0xbffffc14) at sh.c:269
As I see it this is during string conversion of the environment:
STR_environ = blk2short(environ);
As I see it, this is related to a gcc 5 issue with the hand-written calloc in tc.alloc.c,
see the whole thread in http://mx.gw.com/pipermail/tcsh-bugs/2015-May/000933.html.
I'm attaching a working patch (tcsh-6.19.00-calloc-gcc-5.patch). It' the volatile idea
(the last one in the thread).
This should be communicated upstream..
[1] https://github.com/tcsh-org/tcsh/commit/05e7406049bd2686dee0ee8d819dcd38eb131f6f
No sweat. :-)