Bug 1190454
Summary: | stpcpy (mempcpy) segfaults on CPUs without SSE2 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Bruno Wolff III <bruno> |
Component: | glibc | Assignee: | Carlos O'Donell <codonell> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 22 | CC: | admiller, allan, arjun.is, bruno, codonell, evangelos, fweimer, jakub, kdudka, kzak, law, mnewsome, mrmazda, ovasik, p, pfrankli, twaugh |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | glibc-2.21-3.fc22 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-02-05 16:08:17 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Bruno Wolff III
2015-02-08 03:58:44 UTC
It's conceivable though unlikely than a tm_mon outside the range 0..11 is being returned on your platform. This defensive patch would protect against that: diff --git a/src/ls.c b/src/ls.c index cb9d3d6..4698520 100644 --- a/src/ls.c +++ b/src/ls.c @@ -3665,7 +3665,8 @@ align_nstrftime (char *buf, size_t size, char const *fmt, the replacement is not done. A malloc here slows ls down by 2% */ char rpl_fmt[sizeof (abmon[0]) + 100]; const char *pb; - if (required_mon_width && (pb = strstr (fmt, "%b"))) + if (required_mon_width && (pb = strstr (fmt, "%b")) + && 0 <= tm->tm_mon && tm->tm_mon <= 11) { if (strlen (fmt) < (sizeof (rpl_fmt) - sizeof (abmon[0]) + 2)) { If that doesn't help, it does suggest an issue with the stpcpy implementation in libc. In either case running through a debugger would be informative: wget ftp://ftp.gnu.org/pub/gnu/coreutils/coreutils-8.23.tar.xz tar -xf coreutils-8.23.tar.xz cd coreutils-8.23 patch p1 #paste the above ./configure --quiet && make CFLAGS=-ggdb -j3 gdb -tui -args src/ls -l (gdb) b align_nstrftime (gdb) p tm->tm_mon c This doesn't seem to have gone as expected. Some source gets listed after starting, but commands don't seem to be working as expected. │1243 { │ │1244 int i; │ │1245 struct pending *thispend; │ │1246 int n_files; │ │1247 │ │1248 /* The signals that are trapped, and the number of such signals. */ │ │1249 static int const sig[] = │ │1250 { │ │1251 /* This one is handled specially. */ │ │1252 SIGTSTP, │ │1253 │ │1254 /* The usual suspects. */ │ │1255 SIGALRM, SIGHUP, SIGINT, SIGPIPE, SIGQUIT, SIGTERM, │ │1256 #ifdef SIGPOLL │ │1257 SIGPOLL, │ │1258 #endif │ │1259 #ifdef SIGPROF │ │1260 SIGPROF, │ │1261 #endif │ │1262 #ifdef SIGVTALRM │ │1263 SIGVTALRM, │ │1264 #endif │ │1265 #ifdef SIGXCPU │ │1266 SIGXCPU, │ │1267 #endif │ │1268 #ifdef SIGXFSZ │ │1269 SIGXFSZ, For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from src/ls...done. (gdb) b align_nstrftime Breakpoint 1 at 0x804f1df: file src/ls.c, line 3666. (gdb) p tm->tm_mon No symbol "tm" in current context. (gdb) c The program is not being run. (gdb) src/ls -l works normally, while the system ls still segfaults. I added a run step that might have been missing. The month value looked OK for a few iterations. (gdb) p tm->tm_mon $2 = 6 (gdb) c Continuing. Breakpoint 1, align_nstrftime (buf=0xbfffd6f5 "\001-. 1 ", size=1001, fmt=0x805c714 "%b %e %Y", tm=0xb7f1ebc0 <_tmbuf>, __utc=0, __ns=0) at src/ls.c:3666 oops sorry, yes I missed the run step. It's interesting/annoying that only the system version segfaults. Do you have ls aliased to add any time style options etc? Perhaps you have a TIME_STYLE env variable that's not passed through the debugger, in which case you'd need a --time-style to simulate for the command passed to the debugger. Can you reproduce in the debugger for the system version? # yum install coreutils-debuginfo $ gdb -tui -args /usr/bin/ls -l (gdb) b align_nstrftime (gdb) r (gdb) p tm->tm_mon (gdb) c If not reproducible under the debugger, perhaps the TZ env var is different under the debugger and your shell? We had the same issue in Arch Linux with glibc-2.21. This is our proposed fix for glibc: https://sourceware.org/ml/libc-alpha/2015-02/msg00191.html This might be moot now given the above comment, but for completeness: Missing separate debuginfos, use: debuginfo-install libacl-2.2.52-7.fc22.i686 libattr-2.4.47-9.fc22.i686 libcap-2.24-7.fc22.i686 libselinux-2.3-6.fc22. i686 pcre-8.36-3.fc22.i686 xz-libs-5.2.0-2.fc22.i686 (gdb) p tm->tm_mon $1 = 9 (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. 0xb7dc794c in __stpcpy_ia32 () from /lib/libc.so.6 Thanks guys! That confirms the problem is within stpcpy and is mostly likely the issue that Allan identified. Bruno, I am confused as to why your built version didn't also hit the issue. If it was using the gnulib replacement rather than the glibc version it would explain things, but I don't know why it would use the replacement. It's not using the replacement if you see HAVE_STPCPY in the output of `grep STPCPY lib/config.h`. It would be useful to confirm that from the directory where you built coreutils as instructed in comment #1. In my testing 'ls -l' wouldn't segfault when ls.c was built with -O0, only when using -O1 or higher optimization levels. This would explain why Bruno's build worked fine. Any of the ls options produce segfault on my Socket A systems, including the default aliases. ls -l seems to be working again. Thanks for the feedback Bruno. Yep, rawhide 2.21.90-2 uses glibc master branch at commit ebf27d1, which includes the pertinent commit (132a132). http://pkgs.fedoraproject.org/cgit/glibc.git/commit/?id=c6d44c99 (In reply to Bruno Wolff III from comment #12) > ls -l seems to be working again. Running what, a fresh installation, or an upgrade? Upgrading F22 on Socket A host kt880 didn't install a newer coreutils or stop the optioned ls segfaulting: coreutils-8.23-6.fc22.i686 glibc-2.21-1.fc22.i686 glibc-common-2.21-1.fc22.i686 Right, F22 is not updated yet. Note the fix is on the 2.21 branch upstream: https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/release/2.21/master (In reply to Pádraig Brady from comment #15) > Right, F22 is not updated yet. Note the fix is on the 2.21 branch upstream: > https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/release/2.21/ > master F22 has the fix for this bug. The glibc-2.21-1 should not fail. Just to make sure I've bumped the NVR and kicked off a rebuild to redo the testing. Thus glibc-2.21-2.fc22 should absolutely have the fix for this segfault problem, otherwise it's another problem and we need someone to provide some SOS info about the failure e.g. backtrace. Upcoming build: http://koji.fedoraproject.org/koji/taskinfo?taskID=8967632 The patch wasn't applied to the f22 build due to bugs in rpm. These are tracked at bug #1193603 Carlos is working around the issue in a further build. Fixed in glibc-2.21-3.fc22. Final build in progress: http://koji.fedoraproject.org/koji/taskinfo?taskID=8975702 This was fixed in Fedora 22. |