[Bug c++/103629] New: Possible miscompilation triggered by -fvisibility=hidden

[Bug c++/103629] New: Possible miscompilation triggered by -fvisibility=hidden

[mathieu.malaterre at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629

            Bug ID: 103629
           Summary: Possible miscompilation triggered by
                    -fvisibility=hidden
           Product: gcc
           Version: 11.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mathieu.malaterre at gmail dot com
  Target Milestone: ---

Executive summary:
---

```
% LD_LIBRARY_PATH=./openvdb/openvdb ./openvdb/openvdb/cmd/vdb_view
zsh: segmentation fault  LD_LIBRARY_PATH=./openvdb/openvdb
./openvdb/openvdb/cmd/vdb_view
```

Actual bug description:
---

Upon recompilation of openvdb-8.1.0 within a Debian/sid environment, the
initialization logic starts to fails and eventually lead to a segfault.

Inspection of the gdb backtrace does not pinpoint any obvious mistake:

 % LD_LIBRARY_PATH=./openvdb/openvdb gdb ./openvdb/openvdb/cmd/vdb_view
GNU gdb (Debian 10.1-2) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://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 ./openvdb/openvdb/cmd/vdb_view...
(gdb) r --help
Starting program:
/home/malat/openvdb-8.1.0/obj-x86_64-linux-gnu/openvdb/openvdb/cmd/vdb_view
--help
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff6da0640 (LWP 31308)]
[New Thread 0x7ffff659f640 (LWP 31309)]
[New Thread 0x7ffff5d9e640 (LWP 31310)]
[New Thread 0x7ffff559d640 (LWP 31311)]

Thread 1 "vdb_view" received signal SIGSEGV, Segmentation fault.
0x00007ffff78d3228 in std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >::basic_string(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&) ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) bt full
#0  0x00007ffff78d3228 in std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char>
>::basic_string(std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > const&)
    () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#1  0x00007ffff7cac65a in
openvdb::v8_1::Grid<openvdb::v8_1::tree::Tree<openvdb::v8_1::tree::RootNode<openvdb::v8_1::tree::InternalNode<openvdb::v8_1::tree::InternalNode<openvdb::v8_1::tree::LeafNode<bool,
3u>, 4u>, 5u> > > >::gridType[abi:cxx11]() () at
/usr/include/c++/11/bits/unique_ptr.h:173
No locals.
#2 
openvdb::v8_1::Grid<openvdb::v8_1::tree::Tree<openvdb::v8_1::tree::RootNode<openvdb::v8_1::tree::InternalNode<openvdb::v8_1::tree::InternalNode<openvdb::v8_1::tree::LeafNode<bool,
3u>, 4u>, 5u> > > >::registerGrid () at ./openvdb/openvdb/Grid.h:981
No locals.
#3  openvdb::v8_1::initialize () at ./openvdb/openvdb/openvdb.cc:94
        lock = {_M_device = @0x7ffff7fca760}
#4  0x0000555555574c40 in main (argc=<optimized out>, argv=0x7fffffffe4f8) at
./openvdb/openvdb/cmd/openvdb_view.cc:67
        printInfo = <optimized out>
        viewer = {<No data fields>}
        allGrids = std::vector of length 1, capacity -2932030871777 =
{std::shared_ptr<const openvdb::v8_1::GridBase> (use count 1027951951, weak
count 1836017710) = {get() = 0x7fffffffe720},
          std::shared_ptr<const openvdb::v8_1::GridBase> (use count 1831822701,
weak count 1952541792) = {get() = 0x0},
          std::shared_ptr<const openvdb::v8_1::GridBase> (use count 1869361010,
weak count 795631970) = {get() = 0x7fffffffe784},
          std::shared_ptr<const openvdb::v8_1::GridBase> (use count 1330792515,
weak count 1314870350) = {get() = 0x7fffffffe7b4},
          std::shared_ptr<const openvdb::v8_1::GridBase> (use count 1027885383,
weak count 808988978) = {get() = 0x7fffffffe7f1},
          std::shared_ptr<const openvdb::v8_1::GridBase> (use count 1397966163,
weak count 1598967624) = {get() = 0x7fffffffe817},
          std::shared_ptr<const openvdb::v8_1::GridBase> (use count 1380275029,
weak count 1818324284) = {get() = 0x7fffffffe875},
          std::shared_ptr<const openvdb::v8_1::GridBase> (use count 841837938,
weak count 1868772916) = {get() = 0x7fffffffe899},
          std::shared_ptr<const openvdb::v8_1::GridBase> (use count 1027888976,
weak count 1836017710) = {get() = 0x7fffffffe8bc},
          std::shared_ptr<const openvdb::v8_1::GridBase> (use count 1701670760,
weak count 1818324270) = {get() = 0x7fffffffe8cf},
          std::shared_ptr<const openvdb::v8_1::GridBase> (use count 1348426066,
weak count 1028150336) = {get() = 0x7fffffffe938},
          std::shared_ptr<const openvdb::v8_1::GridBase> (use count 1280262912,
weak count 1397640532) = {get() = 0x7fffffffef49}, std::shared_ptr<const
openvdb::v8_1::GridBase> (empty) = {
            get() = 0x7fffffffefa0}, std::shared_ptr<const
openvdb::v8_1::GridBase> (expired, weak count 0) = {get() = 0x21}, <error
reading variable: Cannot access memory at address 0x78bfc07>,
          <error reading variable: Cannot access memory at address 0x1008>,
<error reading variable: Cannot access memory at address 0x6c>,
          std::shared_ptr<const openvdb::v8_1::GridBase> (use count 64, weak
count -1) = {get() = 0x3}, <error reading variable: Cannot access memory at
address 0x40>,
          <error reading variable: Cannot access memory at address 0x13>,
std::shared_ptr<const openvdb::v8_1::GridBase> (expired, weak count 0) = {get()
= 0x7},
          std::shared_ptr<const openvdb::v8_1::GridBase> (empty) = {get() =
0x8}, std::shared_ptr<const openvdb::v8_1::GridBase> (use count -461158174,
weak count 1280594159) = {get() = 0x9},
          <error reading variable: Cannot access memory at address 0xc74>,
<error reading variable: Cannot access memory at address 0xc74>, <error reading
variable: Cannot access memory at address 0xc74>,
          <error reading variable: Cannot access memory at address 0xc74>,
std::shared_ptr<const openvdb::v8_1::GridBase> (empty) = {get() = 0x17},
          std::shared_ptr<const openvdb::v8_1::GridBase> (use count 1418260266,
weak count 1475371345) = {get() = 0x19}, std::shared_ptr<const
openvdb::v8_1::GridBase> (empty) = {get() = 0x1a},
          std::shared_ptr<const openvdb::v8_1::GridBase> (use count 796156268,
weak count 1852141678) = {get() = 0x1f},
          std::shared_ptr<const openvdb::v8_1::GridBase> (use count 1701670760,
weak count 1818324270) = {get() = 0xf}, std::shared_ptr<const
openvdb::v8_1::GridBase> (empty) = {get() = 0x0},
          <error reading variable: Cannot access memory at address
0xf061525488ef2ae4>, <error reading variable: Cannot access memory at address
0x616d2f656d6f6837>,
[--trimmed--]
          <error reading variable: Cannot access memory at address
0x776569765f626c>, <error reading variable allGrids (Cannot access memory at
address 0x7ffffffff000)>
        indent = ""
        printGLInfo = <optimized out>
        printVersionInfo = <optimized out>
        filenames = std::vector of length 4398042310015, capacity 134217727 =
{<error reading variable filenames (Cannot access memory at address 0x1)>
        numFiles = <optimized out>
        progName = 0x7fffffffe763 "vdb_view"
        status = 0
(gdb)


Steps:

```
debian-sid $ dget -u
http://deb.debian.org/debian/pool/main/o/openvdb/openvdb_8.1.0-3.dsc
debian-sid $ cd openvdb-8.1.0
debian-sid $ debuild
```

The above should fails the `help2man` steps which basically simply does:

```
$ cd obj-x86_64-linux-gnu
$ LD_LIBRARY_PATH=./openvdb/openvdb ./openvdb/openvdb/cmd/vdb_view --help
```

1. It should be noticed that the openvdb binaries uploaded in Debian bullseye
(current stable) are working as expected.
2. It should also be noticed that removing of the flag `-fvisibility=hidden`
makes the symptom go away.

As discussed on the gcc-help mailing list, I've been working on reducing the
bug to something useful, but failed to. `c-vise` does not seems to produce
anything meaningful within two hours timelapse. I've been unable to provide the
necessary time to do a brute-force approach (#ifdef-ing the code), so far.


References:
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997080
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001136

% gcc --version
gcc (Debian 11.2.0-12) 11.2.0

% apt-cache policy libtbb2
libtbb2:
  Installed: 2020.3-1
  Candidate: 2020.3-1
  Version table:
 *** 2020.3-1 500

% /lib/x86_64-linux-gnu/libc.so.6
GNU C Library (Debian GLIBC 2.32-5) stable release version 2.32.
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 10.3.1 20211117.
libc ABIs: UNIQUE IFUNC ABSOLUTE
For bug reporting instructions, please see:
<http://www.debian.org/Bugs/>.

[Bug c++/103629] Possible miscompilation triggered by -fvisibility=hidden

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
> debian-sid $ dget -u http://deb.debian.org/debian/pool/main/o/openvdb/openvdb_8.1.0-3.dsc
> debian-sid $ cd openvdb-8.1.0
> debian-sid $ debuild

Would it be possible reproducing the issue with the build from source? The
instructions seem to be very Debian-specific.

[Bug c++/103629] Possible miscompilation triggered by -fvisibility=hidden

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
-fvisibility=hidden hides typeinfo so it could be possibility of having two
typeinfo for the same class in if not used correctly.

[Bug c++/103629] Possible miscompilation triggered by -fvisibility=hidden

[mathieu.malaterre at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629

--- Comment #3 from Mathieu Malaterre <mathieu.malaterre at gmail dot com> ---
Steps to reproduce without a full Debian environement:

```
$ wget
http://deb.debian.org/debian/pool/main/o/openvdb/openvdb_8.1.0.orig.tar.xz
$ tar xf openvdb_8.1.0.orig.tar.xz
$ cd openvdb-8.1.0
$ mkdir build
$ cd build
$ export CXXFLAGS=-fvisibility=hidden
$ cmake .. -DOPENVDB_BUILD_VDB_VIEW:BOOL=ON
$ make -j8 vdb_view
$ LD_LIBRARY_PATH=./openvdb/openvdb ./openvdb/openvdb/cmd/vdb_view
```

[Bug c++/103629] Possible miscompilation triggered by -fvisibility=hidden

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Mathieu Malaterre from comment #3)
> $ export CXXFLAGS=-fvisibility=hidden

Yes you can't just use -fvisibility=hidden without the source being ready for
it.

[Bug c++/103629] Possible miscompilation triggered by -fvisibility=hidden

[mathieu.malaterre at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629

--- Comment #5 from Mathieu Malaterre <mathieu.malaterre at gmail dot com> ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Mathieu Malaterre from comment #3)
> > $ export CXXFLAGS=-fvisibility=hidden
> 
> Yes you can't just use -fvisibility=hidden without the source being ready
> for it.

Andrew, could you please be a bit more specific. I do not see any changes
related to duplicate `typeinfo` or `visibility=hidden` in the changelog:

* https://gcc.gnu.org/gcc-11/changes.html

`-fvisibility=hidden` was added in 2015 in the Debian/OpenVDB package and has
worked quite well for all users so far. It would be nice if gcc/ld would help
track any `type_info` issue, in large portable c++ codebase.

*
https://salsa.debian.org/multimedia-team/openvdb/-/blob/debian/3.0.0-1/debian/rules#L14-15

[Bug c++/103629] Possible miscompilation triggered by -fvisibility=hidden

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Mathieu Malaterre from comment #5)
> (In reply to Andrew Pinski from comment #4)
> > (In reply to Mathieu Malaterre from comment #3)
> > > $ export CXXFLAGS=-fvisibility=hidden
> > 
> > Yes you can't just use -fvisibility=hidden without the source being ready
> > for it.
> 
> Andrew, could you please be a bit more specific. I do not see any changes
> related to duplicate `typeinfo` or `visibility=hidden` in the changelog:
> 
> * https://gcc.gnu.org/gcc-11/changes.html

right there has been no major changes in this area as far as I Know. 

> 
> `-fvisibility=hidden` was added in 2015 in the Debian/OpenVDB package and
> has worked quite well for all users so far. It would be nice if gcc/ld would
> help track any `type_info` issue, in large portable c++ codebase.

It was working by accident before. Do you know why it was added? Has the code
upstream in OpenVDB been fixed for adding the visibility attribute where
needed?

[Bug c++/103629] Possible miscompilation triggered by -fvisibility=hidden

[mathieu.malaterre at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629

--- Comment #7 from Mathieu Malaterre <mathieu.malaterre at gmail dot com> ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Mathieu Malaterre from comment #5)
> > (In reply to Andrew Pinski from comment #4)
> > > (In reply to Mathieu Malaterre from comment #3)
> > > > $ export CXXFLAGS=-fvisibility=hidden
> > > 
> > > Yes you can't just use -fvisibility=hidden without the source being ready
> > > for it.
> > 
> > Andrew, could you please be a bit more specific. I do not see any changes
> > related to duplicate `typeinfo` or `visibility=hidden` in the changelog:
> > 
> > * https://gcc.gnu.org/gcc-11/changes.html
> 
> right there has been no major changes in this area as far as I Know. 
> 
> > 
> > `-fvisibility=hidden` was added in 2015 in the Debian/OpenVDB package and
> > has worked quite well for all users so far. It would be nice if gcc/ld would
> > help track any `type_info` issue, in large portable c++ codebase.
> 
> It was working by accident before. Do you know why it was added? Has the
> code upstream in OpenVDB been fixed for adding the visibility attribute
> where needed?

OpenVDB is supposed to be /portable/ c++. The dll export mechanism has been
working on windows arch since basically day-one.

The gcc implementation is at:

*
https://github.com/AcademySoftwareFoundation/openvdb/blob/master/openvdb/openvdb/Platform.h#L218-L219

IMHO this is following the wiki from:

* https://gcc.gnu.org/wiki/Visibility

[Bug c++/103629] Possible miscompilation triggered by -fvisibility=hidden

[mathieu.malaterre at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629

--- Comment #8 from Mathieu Malaterre <mathieu.malaterre at gmail dot com> ---
 % more CMakeLists.txt main.cc Module.cc openvdb.cc Tree.h
::::::::::::::
CMakeLists.txt
::::::::::::::
cmake_minimum_required(VERSION 3.13)
project(p)

# only export limited set of symbols
set(CMAKE_C_VISIBILITY_PRESET hidden)
set(CMAKE_CXX_VISIBILITY_PRESET hidden)
set(CMAKE_VISIBILITY_INLINES_HIDDEN 1)

# important to have pthread at runtime:
set(CMAKE_THREAD_PREFER_PTHREAD TRUE)
set(THREADS_PREFER_PTHREAD_FLAG TRUE)
find_package(Threads REQUIRED)

# important to use SHARED:
add_library(openvdb SHARED openvdb.cc)
target_include_directories(openvdb PRIVATE ${CMAKE_CURRENT_SOURCE_DIR})

add_executable(vdb_view main.cc Module.cc)
target_link_libraries(vdb_view openvdb Threads::Threads)
target_include_directories(vdb_view PRIVATE ${CMAKE_CURRENT_SOURCE_DIR})
::::::::::::::
main.cc
::::::::::::::
void initialize();

int main(int , char *[])
{
    initialize();
    return 0;
}
::::::::::::::
Module.cc
::::::::::::::
#include "Tree.h"

class Module
{
    void init();
};

void Module::init() // no-inline
{
   Tree::treeType();
}
::::::::::::::
openvdb.cc
::::::::::::::
#include "Tree.h"

static std::string do_segfault() { return Tree::treeType(); }

 __attribute__((visibility("default")))
void initialize()
{
  do_segfault();
}
::::::::::::::
Tree.h
::::::::::::::
#pragma once

#include <mutex>
#include <memory>

class Tree
{
public:
    static const std::string treeType() {
      static std::once_flag once;
      std::call_once(once, []() {
        sTreeTypeName.reset(new std::string());
                      });
      return *sTreeTypeName;
    }
private:
    static std::unique_ptr<const std::string> sTreeTypeName;
};

std::unique_ptr<const std::string> Tree::sTreeTypeName;

[Bug c++/103629] Possible miscompilation triggered by pthread + exception

[mathieu.malaterre at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629

--- Comment #9 from Mathieu Malaterre <mathieu.malaterre at gmail dot com> ---
Compiling the reduce test case without pthread lead to some kind of exception:

```
(gdb) bt full
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
        set = {__val = {0 <repeats 12 times>, 8245935278387129975,
5908832823118463008, 0, 0}}
        pid = <optimized out>
        tid = <optimized out>
        ret = <optimized out>
#1  0x00007ffff7bf9536 in __GI_abort () at abort.c:79
        save_stage = 1
        act = {__sigaction_handler = {sa_handler = 0x7ffff7d925e0
<_IO_2_1_stderr_>, sa_sigaction = 0x7ffff7d925e0 <_IO_2_1_stderr_>}, sa_mask =
{__val = {140737350282933, 140737351591392, 140737351591392,
              140737351591523, 140737351595200, 3432, 140737350279750, 11, 1,
140737351591392, 93824992325712, 140737352586656, 140737488347968, 0,
140737350287193, 140737351591840}}, sa_flags = -135945484,
          sa_restorer = 0x7ffff7d927a0 <stderr>}
        sigs = {__val = {32, 0, 0, 0, 17, 9223372036854775922, 140737352422480,
140737350282933, 0, 140737350282933, 140737353353159, 140737351591392,
93824992325672, 140737351595200, 3432, 140737350279750}}
#2  0x00007ffff7e4f87a in __gnu_cxx::__verbose_terminate_handler () at
../../../../src/libstdc++-v3/libsupc++/vterminate.cc:95
        terminating = true
        t = <optimized out>
#3  0x00007ffff7e5b04a in __cxxabiv1::__terminate (handler=<optimized out>) at
../../../../src/libstdc++-v3/libsupc++/eh_terminate.cc:48
No locals.
#4  0x00007ffff7e5b0b5 in std::terminate () at
../../../../src/libstdc++-v3/libsupc++/eh_terminate.cc:58
No locals.
#5  0x00007ffff7e5b349 in __cxxabiv1::__cxa_throw (obj=<optimized out>,
tinfo=0x7ffff7fb1530 <typeinfo for std::system_error>, dest=0x7ffff7e855a0
<std::system_error::~system_error()>)
    at ../../../../src/libstdc++-v3/libsupc++/eh_throw.cc:95
        globals = <optimized out>
        header = 0x55555556aeb0
#6  0x00007ffff7e525fa in std::__throw_system_error(int) () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#7  0x00007ffff7fc740f in
std::call_once<Tree::treeType()::{lambda()#1}>(std::once_flag&,
Tree::treeType()::{lambda()#1}&&) (__once=..., __f=...) at
/usr/include/c++/11/mutex:784
        __e = -1
        __callable = {____f = @0x7fffffffe3ff}
        __exec = {<No data fields>}
```

I am not able to reproduce gcc behavior using clang++ (again Debian sid
version).

[Bug c++/103629] Possible miscompilation visible using pthread + exception

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |---
             Status|RESOLVED                    |UNCONFIRMED

--- Comment #10 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I think this is solved on the trunk. The issue is not with visibility hidden
but rather with the newer glibc.

[Bug libstdc++/103629] Possible miscompilation visible using pthread + exception

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629

--- Comment #11 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Plus please don't use cmake and just make a simple makefile for testcases like
this  cnake brings in a lot of crap for no reason.

[Bug libstdc++/103629] Possible miscompilation visible using pthread + exception

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629

--- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Simple makefile for comment 8:

CXXFLAGS := -fvisibility=hidden -fvisibility-inlines-hidden

vdb_view: main.o Module.o libopenvdb.so
        $(CXX) -o $@ $^ -pthread '-Wl,-rpath,$$ORIGIN'
libopenvdb.so: openvdb.cc
        $(CXX) $(CXXFLAGS) -fPIC -shared -Wl,-soname,libopenvdb.so -o $@ $<
clean:
        rm -f main.o Module.o libopenvdb.so

[Bug libstdc++/103629] Possible miscompilation visible using pthread + exception

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629

--- Comment #13 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Inside the lambda run by std::call_once, the address of sTreeTypeName is
0x404098, but after std::call_once finishes, the address of the object being
dereferenced is 0x7ffff7fc2090

[Bug libstdc++/103629] Possible miscompilation visible using pthread + exception

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629

--- Comment #14 from Jonathan Wakely <redi at gcc dot gnu.org> ---
So one copy of that variable gets initialized, and a different copy gets
dereferenced, so it dereferences null.

If you change Tree.h to:

#pragma once

#include <mutex>
#include <memory>
#include <cstdio>

class Tree
{
public:
    static const std::string treeType() {
      static std::once_flag once;
      std::call_once(once, []() {
        std::printf("%p\n", &sTreeTypeName);
        sTreeTypeName.reset(new std::string());
                      });
      std::printf("%p\n", &sTreeTypeName);
      if (!sTreeTypeName)
        throw "uhoh";
      return *sTreeTypeName;
    }
private:
    static std::unique_ptr<const std::string> sTreeTypeName;
};

std::unique_ptr<const std::string> Tree::sTreeTypeName;

The program prints:

0x4040b0
0x7f81066af0a8
terminate called after throwing an instance of 'char const*'
Aborted (core dumped)

[Bug libstdc++/103629] Possible miscompilation visible using pthread + exception

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629

--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #12)
> Simple makefile for comment 8:

A better one:

CXXFLAGS := -fvisibility=hidden -fvisibility-inlines-hidden -g
LDFLAGS := '-Wl,-rpath,$$ORIGIN' -pthread -L.
LDLIBS := -lopenvdb
OBJS := main.o Module.o
LIB := libopenvdb.so

vdb_view: $(OBJS) $(LIB)
        $(CXX) -o $@ $(OBJS) $(LDFLAGS) $(LDLIBS)
Module.o: Tree.h
$(LIB): openvdb.cc Tree.h
        $(CXX) $(CXXFLAGS) -fPIC -shared -Wl,-soname,$@ -o $@ $<
clean:
        rm -f $(OBJS) $(LIB)

[Bug libstdc++/103629] Possible miscompilation visible using pthread + exception

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629

--- Comment #16 from Jonathan Wakely <redi at gcc dot gnu.org> ---
With GCC 10 the same object gets used in the lambda and outside it:

0x7f52ed99f090
0x7f52ed99f090

[Bug libstdc++/103629] Possible miscompilation visible using pthread + exception

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629

--- Comment #17 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The difference is due to this change in std::call_once


-      __once_callable = std::__addressof(__callable); // NOLINT: PR 82481
-      __once_call = []{ (*(decltype(__callable)*)__once_callable)(); };
+      once_flag::_Prepare_execution __exec(__callable);

But I don't know why.

[Bug libstdc++/103629] Possible miscompilation visible using pthread + exception

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629

--- Comment #18 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Could Visibility not being applied correctly to lambdas but does that matter?

[Bug libstdc++/103629] [11/12 Regression] Possible miscompilation visible using pthread + exception

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Possible miscompilation     |[11/12 Regression] Possible
                   |visible using pthread +     |miscompilation visible
                   |exception                   |using pthread + exception
   Target Milestone|---                         |11.3

[Bug libstdc++/103629] [11/12 Regression] Possible miscompilation visible using pthread + exception

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-01-04
     Ever confirmed|0                           |1
           Priority|P3                          |P2
             Status|UNCONFIRMED                 |NEW

--- Comment #19 from Richard Biener <rguenth at gcc dot gnu.org> ---
Seems confirmed at least.

[Bug libstdc++/103629] [11/12 Regression] Possible miscompilation visible using pthread + exception

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.3                        |11.4

--- Comment #20 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 11.3 is being released, retargeting bugs to GCC 11.4.

[Bug libstdc++/103629] [11/12/13 Regression] Possible miscompilation visible using pthread + exception

[malat at debian dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629

--- Comment #22 from Mathieu Malaterre <malat at debian dot org> ---
Created attachment 53501
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53501&action=edit
working save-temps

[Bug libstdc++/103629] [11/12/13 Regression] Possible miscompilation visible using pthread + exception

[malat at debian dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629

--- Comment #23 from Mathieu Malaterre <malat at debian dot org> ---
Created attachment 53502
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53502&action=edit
non-working save-temps

[Bug libstdc++/103629] [11/12/13 Regression] Possible miscompilation visible using pthread + exception

[malat at debian dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629

--- Comment #24 from Mathieu Malaterre <malat at debian dot org> ---
I have change the openvdb.cc code into:

% cat openvdb.cc
#include "Tree.h"

static std::string do_segfault() { return Tree::treeType(); }

#ifdef VIS
__attribute__((visibility("default")))
#endif
void initialize()
{
  do_segfault();
}

Now I can demonstrate that the issue only happen when using the visibility flag
(no-symptom using the default UNIX mechanism to export all symbols).

[Bug libstdc++/103629] [11/12/13 Regression] wrong-code when mixing mutex with visibility=hidden

[malat at debian dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629

--- Comment #25 from Mathieu Malaterre <malat at debian dot org> ---
Looks like there is an easy fix (work-around?):

% cat Tree.h
#pragma once

#include <memory>
#include <mutex>

class
#ifdef VIS
__attribute__((visibility("default")))
#endif
Tree {
public:
  static const std::string treeType() {
    static std::once_flag once;
    std::call_once(once, []() {
      std::printf("%p\n", &sTreeTypeName);
      sTreeTypeName.reset(new std::string());
    });
    std::printf("%p\n", &sTreeTypeName);
    if (!sTreeTypeName)
      throw "uhoh";
    return *sTreeTypeName;
  }

private:
  static std::unique_ptr<const std::string> sTreeTypeName;
};

std::unique_ptr<const std::string> Tree::sTreeTypeName;

[Bug libstdc++/103629] [11/12/13 Regression] wrong-code when mixing mutex with visibility=hidden

[malat at debian dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629

--- Comment #26 from Mathieu Malaterre <malat at debian dot org> ---
This may be related to:

* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62280

[Bug libstdc++/103629] [11/12/13 Regression] wrong-code when mixing mutex with visibility=hidden

[malat at debian dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629

--- Comment #27 from Mathieu Malaterre <malat at debian dot org> ---
Symptom may go away with:

* https://github.com/AcademySoftwareFoundation/openvdb/pull/1589

[Bug libstdc++/103629] [11/12/13/14 Regression] wrong-code when mixing mutex with visibility=hidden

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.4                        |11.5

--- Comment #28 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 11.4 is being released, retargeting bugs to GCC 11.5.