Bug 1558107
| Summary: | strerror_r returns a malformed buffer | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Robbie Harwood <rharwood> | ||||
| Component: | valgrind | Assignee: | Mark Wielaard <mjw> | ||||
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 32 | CC: | arjun.is, codonell, dj, dodji, fweimer, jakub, law, mfabian, mjw, pfrankli, rharwood, rth, siddhesh | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | i686 | ||||||
| OS: | Unspecified | ||||||
| URL: | https://bugs.kde.org/show_bug.cgi?id=401719 | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2021-05-25 14:58:16 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: | |||||||
| Attachments: |
|
||||||
Sorry, I can't reproduce this with: gcc-8.0.1-0.18.fc29.x86_64 glibc-2.27.9000-10.fc29.x86_64 glibc-2.27.9000-10.fc29.i686 What are your exact gcc and and glibc versions, and how do you compile the program? [root@rawhide32 tmp]# gcc -O0 -ggdb -std=c99 test.c -o test [root@rawhide32 tmp]# valgrind ./test ==16919== Memcheck, a memory error detector ==16919== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==16919== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==16919== Command: ./test ==16919== ==16919== ==16919== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==16919== General Protection Fault ==16919== at 0x80485B4: main (test.c:23) ==16919== ==16919== HEAP SUMMARY: ==16919== in use at exit: 0 bytes in 0 blocks ==16919== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==16919== ==16919== All heap blocks were freed -- no leaks are possible ==16919== ==16919== For counts of detected and suppressed errors, rerun with: -v ==16919== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Violación de segmento [root@rawhide32 tmp]# rpm -qv glibc gcc glibc-2.27.9000-10.fc29.i686 gcc-8.0.1-0.18.fc29.i686 [root@rawhide32 tmp]# Oh. So the crash only happens under valgrind? Interesting. The crash happens here: 0x080485ac <+198>: call 0x80483b0 <strncpy@plt> 0x080485b1 <+203>: add $0x10,%esp => 0x080485b4 <+206>: movb $0x0,%gs:0xffffffff 0x080485bc <+214>: sub $0xc,%esp 0x080485bf <+217>: mov %gs:0x0,%eax Now this may look suspiciously broken, but the binary has a static TLS allocation, so this might actually be legitimate, and thread_pointer[-1] could in fact be the last byte in the TLS buffer. *** Bug 1558111 has been marked as a duplicate of this bug. *** I can replicate this by compiling the repoducer with gcc -m32 -g -o repo and running under valgrind.i686. Breaking in gdb at that point gives: Starting program: /home/mark/repo Temporary breakpoint 1, main (argc=1, argv=0xffffd2a4) at repo.c:15 15 ret = strerror_r(2, buf, MAX_GP_STRERROR); (gdb) break *0x8048594 Breakpoint 2 at 0x8048594: file repo.c, line 23. (gdb) c Continuing. Breakpoint 2, main (argc=1, argv=0xffffd2a4) at repo.c:23 23 buf[MAX_GP_STRERROR -1] = '\0'; (gdb) print buf Cannot find thread-local storage for process 10993, executable file /home/mark/repo: Cannot find thread-local variables on this target hmmm (gdb) info registers eax 0xf7fabf80 -134561920 ecx 0x0 0 edx 0x3e7 999 ebx 0x0 0 esp 0xffffd1e0 0xffffd1e0 ebp 0xffffd1f8 0xffffd1f8 esi 0xf7fa7000 -134582272 edi 0x0 0 eip 0x8048594 0x8048594 <main+206> eflags 0x282 [ SF IF ] cs 0x23 35 ss 0x2b 43 ds 0x2b 43 es 0x2b 43 fs 0x0 0 gs 0x63 99 Removing the __thread marker from the buf array does make things work fine under valgrind.i686 When run under valgrind with --vgdb-error=0 (gdb) target remote | /usr/lib/valgrind/../../bin/vgdb --pid=11038 Remote debugging using | /usr/lib/valgrind/../../bin/vgdb --pid=11038 relaying data between gdb and process 11038 warning: remote target does not support file transfer, attempting to access files from local filesystem. Reading symbols from /lib/ld-linux.so.2...Reading symbols from /opt/lib/debug/usr/lib/ld-2.26.so.debug...done. done. 0x04000b50 in _start () from /lib/ld-linux.so.2 (gdb) break *0x8048594 Breakpoint 1 at 0x8048594: file repo.c, line 23. (gdb) c Continuing. Breakpoint 1, main (argc=1, argv=0xfedc0214) at repo.c:23 23 buf[MAX_GP_STRERROR -1] = '\0'; (gdb) print buf $1 = "No such file or directory", '\000' <repeats 998 times> (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. main (argc=1, argv=0xfedc0214) at repo.c:23 23 buf[MAX_GP_STRERROR -1] = '\0'; (gdb) info registers eax 0x402c280 67289728 ecx 0x402c299 67289753 edx 0x400 1024 ebx 0x0 0 esp 0xfedc0150 0xfedc0150 ebp 0xfedc0168 0xfedc0168 esi 0x41f6000 69165056 edi 0x0 0 eip 0x8048594 0x8048594 <main+206> eflags 0x84 [ PF SF ] cs 0x2b0023 2818083 ss 0x2b 43 ds 0x2b002b 2818091 es 0x2b 43 fs 0xb0000 720896 gs 0x2b000b 2818059 I think this is a valgrind problem. This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle. Changing version to '29'. (Per comment #7.) (In reply to Robbie Harwood from comment #9) > (Per comment #7.) Still seems an issue on i386 with valgrind 3.14.0 Might be best to file a bug upstream: http://valgrind.org/support/bug_reports.html Note that i386 support is kind of in maintenance mode and upstream encourages upgrading to amd64 wherever possible. You can't upgrade a distro just by willing it. As long as Fedora supports 32-bit x86, we need to be able to build there - which means the tooling needs to work there. Maintenance mode still requires *maintenance*, from maintainers. (In reply to Robbie Harwood from comment #11) > You can't upgrade a distro just by willing it. As long as Fedora supports > 32-bit x86, we need to be able to build there - which means the tooling > needs to work there. Maintenance mode still requires *maintenance*, from > maintainers. If you need new features from upstream, please do report a bug. I am not saying they will not implement it. It might be easy. But new features for i386 are not a priority when people can use x86_64 mode. It's not a new feature. valgrind on 32-bit x86 is broken. I shouldn't be able to get valgrind to GPF. Generally I'd consider it the maintainer's responsibility to forward bugs upstream as part of fixing them where needed; doubly so because upstream's bugtracker requires creating an account. You don't have an account that I could find there either, so please add yourself to CC: https://bugs.kde.org/show_bug.cgi?id=401719 This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Checked still occurs. # rpm -qv gcc glibc valgrind gcc-9.2.1-1.fc32.3.i686 glibc-2.30.9000-16.fc32.i686 valgrind-3.15.0-12.fc32.i686 This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle. Changing version to 32. This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |
Created attachment 1409995 [details] minimized reproducer On i686, running the attached code under valgrind causes a GPF: ==16411== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==16411== General Protection Fault ==16411== at 0x80485B4: main (in /tmp/test) Examination of the core indicates that: Program terminated with signal SIGSEGV, Segmentation fault. #0 main (argc=1, argv=0xbecaac44) at test.c:23 23 buf[MAX_GP_STRERROR -1] = '\0'; This code has been in gssproxy for some time.