Bug 1672436
Summary: | wrong-code: LLDB testcase fails: SymbolFile/DWARF/find-basic-namespace.cpp | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jan Kratochvil <jan.kratochvil> | ||||||||
Component: | gcc | Assignee: | Jakub Jelinek <jakub> | ||||||||
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
Severity: | high | Docs Contact: | |||||||||
Priority: | unspecified | ||||||||||
Version: | 29 | CC: | davejohansen, dmalcolm, fweimer, jakub, jan.kratochvil, jwakely, law, mpolacek, msebor, nickc | ||||||||
Target Milestone: | --- | ||||||||||
Target Release: | --- | ||||||||||
Hardware: | x86_64 | ||||||||||
OS: | Linux | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2019-11-27 22:50:03 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: |
|
Description
Jan Kratochvil
2019-02-04 22:52:47 UTC
Created attachment 1526894 [details]
local GCC bisecting script
Let me make sure I understand what the results mean: the test failures happen with gcc-8_2_0-release and prior but not with GCC trunk, or with 8.2 and Jeff's patch applied. If that's close, the likely cause of the failures is assuming strings can span multiple members of a struct, like in this test case where GCC 8 returns 0 but GCC 9 returns 1: struct S { char a[4], b[8]; } s; int f (void) { for (int i = 0; i != 4; ++i) s.a[i] = 'x'; s.b[0] = 0; return strlen (s.a) == 4; // undefined, folded to 0 in GCC 8 and to 1 in GCC 9 } Is this LLDB code behavior really undefined? I would say it does not matter what strlen() returns as there is that std::min() protection: #include <algorithm> #include <string.h> // lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp:1731 static struct section_64 { char sectname[16]; char segname[16]; } sect64 = { {'_','_','a','p','p','l','e','_','n','a','m','e','s','p','a','c'}, "__DWARF" }; int main() { return std::min<size_t>(strlen(sect64.sectname), sizeof(sect64.sectname)); } gcc-8.2.1-6.fc29.x86_64 g++ -o strlen strlen.C -Wall -g -O2;./strlen;echo $? Actual: 23 Expected: 16 (In reply to Jan Kratochvil from comment #3) > Is this LLDB code behavior really undefined? I would say it does not matter > what strlen() returns as there is that std::min() protection: https://en.wikipedia.org/wiki/Undefined_behavior "In general, any instance of undefined behavior leaves the abstract execution machine in an unknown state, and causes the behavior of the entire program to be undefined." So OK, I expect this will be CLOSED-NOTABUG and going to submit an LLDB fix. Isn't strnlen what they are looking for? It's definitely undefined. It doesn't matter that the value of strlen is clamped *after* running off the end of the array, that's too late. I thought we already fixed this in LLDB, but maybe that was something very similar in LLVM. Created attachment 1527275 [details] LLDB strnlen.patch (In reply to Jakub Jelinek from comment #5) > Isn't strnlen what they are looking for? This is what I am going to submit. Maybe it was some microoptimization, they care about runtime performance a lot. It was in LLD and tstellar fixed it: https://github.com/llvm-mirror/lld/commit/c0aa57c9cbaca0f14bde7a78b067e947ccfbd672#diff-00e2f6bb89e280599d22538d8533ae78 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. Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 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. |