Bug 1672436 - wrong-code: LLDB testcase fails: SymbolFile/DWARF/find-basic-namespace.cpp
Summary: wrong-code: LLDB testcase fails: SymbolFile/DWARF/find-basic-namespace.cpp
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc
Version: 29
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-02-04 22:52 UTC by Jan Kratochvil
Modified: 2019-11-27 22:50 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-11-27 22:50:03 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
find-basic-namespace.cpp.tmp.xz (988 bytes, application/x-xz)
2019-02-04 22:52 UTC, Jan Kratochvil
no flags Details
local GCC bisecting script (799 bytes, text/plain)
2019-02-04 22:53 UTC, Jan Kratochvil
no flags Details
LLDB strnlen.patch (1.87 KB, patch)
2019-02-05 20:15 UTC, Jan Kratochvil
no flags Details | Diff

Description Jan Kratochvil 2019-02-04 22:52:47 UTC
Created attachment 1526893 [details]
find-basic-namespace.cpp.tmp.xz

Description of problem:
LLDB testsuite can FAIL for:
    LLDB :: SymbolFile/DWARF/find-basic-namespace.cpp
It fails with F-29 GCC but it works fine with trunk GCC.

Version-Release number of selected component (if applicable):
FAIL: gcc-8.2.1-6.fc29.x86_64
FAIL: gcc-8.2.1-7.fc29.x86_64
FAIL: 9fb89fa845c1b2e0a18d85ada0b077c84508ab78 = gcc-8_2_0-release
PASS: 934ccfef21c68278e81e5fe2015fb68ec39ed18a = trunk
I have not tested Rawhide GCC.
x
FAIL: -DCMAKE_BUILD_TYPE=Release (the tests above)
PASS: -DCMAKE_BUILD_TYPE=Debug (with gcc-8.2.1-6.fc29.x86_64)
x
FAIL: ""
PASS: -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ (GCC not used)

How reproducible:
Always.

Steps to Reproduce:
git clone https://github.com/llvm/llvm-project.git llvm-monorepo
mkdir llvm-monorepo-build
cd llvm-monorepo-build
export LD_LIBRARY_PATH=GCCPATH/lib64
cmake ../llvm-monorepo/llvm/ -DCMAKE_BUILD_TYPE=Release -DLLVM_USE_LINKER=gold -DLLVM_ENABLE_PROJECTS="lldb;clang;lld" -DCMAKE_C_COMPILER=GCCPATH/bin/gcc -DCMAKE_CXX_COMPILER=GCCPATH/bin/g++
make

python2 ./bin/llvm-lit -sv tools/lldb/lit --filter find-basic-namespace
OR
./bin/lldb-test symbols --name=foo --find=namespace ATTACHED/find-basic-namespace.cpp.tmp

Actual results:
Module: /home/jkratoch/t/find-basic-namespace.cpp.tmp
Namespace not found.

Expected results:
Module: /home/jkratoch/t/find-basic-namespace.cpp.tmp
Found namespace: foo

Additional info:
ff8064bd9580dd182c7d6a209be774a65c7fdbc7 is the first bad(=good) commit
commit ff8064bd9580dd182c7d6a209be774a65c7fdbc7
Author: law <law@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Wed Jan 2 21:38:56 2019 +0000
            * gimple-fold.c (gimple_fold_builtin_strlen): Use set_strlen_range
...
    git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@267531 138bc75d-0d04-0410-961f-82ee72b054a4
->
Message-ID: <0886b52b-92f0-f02d-d588-c43bcd0e806c>
->
[committed] Be more conservative with string length range computations
From: Jeff Law <law at redhat dot com>
https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00069.html

I have no idea what's wrongly compiled in lldb-test, I did not debug it.

I guess RHEL-8 gcc is also affected.

Comment 1 Jan Kratochvil 2019-02-04 22:53:31 UTC
Created attachment 1526894 [details]
local GCC bisecting script

Comment 2 Martin Sebor 2019-02-05 00:05:21 UTC
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
  }

Comment 3 Jan Kratochvil 2019-02-05 19:25:09 UTC
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

Comment 4 Jan Kratochvil 2019-02-05 20:03:37 UTC
(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.

Comment 5 Jakub Jelinek 2019-02-05 20:11:02 UTC
Isn't strnlen what they are looking for?

Comment 6 Jonathan Wakely 2019-02-05 20:11:16 UTC
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.

Comment 7 Jan Kratochvil 2019-02-05 20:15:54 UTC
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.

Comment 9 Ben Cotton 2019-10-31 19:08:57 UTC
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.

Comment 10 Ben Cotton 2019-11-27 22:50:03 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.