Crash during program startup when linking against Boost regex library - c++

Our project (in C++) needs to link against boost regex so we just locate the correct compiled libboost_regex_1.45.0 and tell g++ to link against it. Compiling is successful and we just get the right executable as expected. The problem is, each time we try to run the executable, it crashes before entering main() routine.
Attaching the generated core file with gdb, the backtrace command shows there's a segmentation fault during __bultin_strlen, which is resolved to strlen##GLBC_2.2.5.
Since our executable is linked against several dynamic libraries, readelf -s is harnessed to identify the problematic symbol and it boils down to libboost_regex. However the referred symbol is already there in RHEL6 system folder /lib64/libc.so.
The question is, how can we get boost regex working properly?
OS: RHEL6.2
GCC: 4.3.2 / libstdc++6.0.13
Boost libraries is built by exactly the same toolset - user-config.bjam is customized
Static linking is not a good choice for us for various reasons.
The symbol info and ldd info is attached at https://gist.github.com/skyscribe/5184622

From the gdb backtrace, we see that the std::char_traits<char>::length method with argument \"http:\\\\/\\\\/localhostr.com\\\\/files\\\\/.+?\" is triggering the segmentation fault. g++ 4.3.2 introduced new Stack Smashing Protection features, which may interfere with the strlen length computation.
Recompile/relink your code with a recent g++ compiler and see if you solve this error. This sample code does not reproduce such error:
user#workstation ~
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-cygwin/4.5.3/lto-wrapper.exe
Target: i686-pc-cygwin
Configured with: /gnu/gcc/releases/respins/4.5.3-3/gcc4-4.5.3-3/src/gcc-4.5.3/configure --srcdir=/gnu/gcc/releases/respins/4.5.3-3/gcc4-4.5.3-3/src/gcc-4.5.3 --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/lib --datadir=/usr/share --localstatedir=/var --sysconfdir=/etc --datarootdir=/usr/share --docdir=/usr/share/doc/gcc4 -C --datadir=/usr/share --infodir=/usr/share/info --mandir=/usr/share/man -v --with-gmp=/usr --with-mpfr=/usr --enable-bootstrap --enable-version-specific-runtime-libs --libexecdir=/usr/lib --enable-static --enable-shared --enable-shared-libgcc --disable-__cxa_atexit --with-gnu-ld --with-gnu-as --with-dwarf2 --disable-sjlj-exceptions --enable-languages=ada,c,c++,fortran,java,lto,objc,obj-c++ --enable-graphite --enable-lto --enable-java-awt=gtk --disable-symvers --enable-libjava --program-suffix=-4 --enable-libgomp --enable-libssp --enable-libada --enable-threads=posix --with-arch=i686 --with-tune=generic --enable-libgcj-sublibs CC=gcc-4 CXX=g++-4 CC_FOR_TARGET=gcc-4 CXX_FOR_TARGET=g++-4 GNATMAKE_FOR_TARGET=gnatmake GNATBIND_FOR_TARGET=gnatbind --with-ecj-jar=/usr/share/java/ecj.jar
Thread model: posix
gcc version 4.5.3 (GCC)
user#workstation ~
$ cat test.cc
#include <iostream>
#include <string>
int main(int argc, char *argv[]) {
char * a = "\"http:\\\\/\\\\/localhostr.com\\\\/files\\\\/.+?\"";
int t = std::char_traits<char>::length (a);
std::cout << t << std::endl;
}
user#workstation ~
$ g++ -g test.cc
test.cc: In function ‘int main(int, char**)’:
test.cc:6:14: warning: deprecated conversion from string constant to ‘char*’
user#workstation ~
$ gdb a.exe
Reading symbols from /home/user/a.exe...done.
(gdb) b std::char_traits<char>::length
Breakpoint 1 at 0x4017f6: file /usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/bits/char_traits.h, line 263.
(gdb) r
Starting program: /home/user/a.exe
[New Thread 764.0x5e4]
[New Thread 764.0x100c]
Breakpoint 1, std::char_traits<char>::length (__s=0x402080 "\"http:\\\\/\\\\/localhostr.com\\\\/files\\\\/.+?\"") at /usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/bits/char_traits.h:263
263 { return __builtin_strlen(__s); }
(gdb) c
Continuing.
41
[Inferior 1 (process 764) exited normally]
(gdb)

Related

GCC v12.1 warning about serial compilation

I have upgraded my whole arch linux system today (12th May, 2022). gcc was also upgraded from v11.2 to v12.1. I tried compiling some of my programs with g++ (part of gcc compiler collection) by the following command:
g++ -O3 -DNDEBUG -Os -Ofast -Og -s -march=native -flto -funroll-all-loops -std=c++20 main.cc -o ./main
The program compiled perfectly and ran as excepted without any errors, but I got a warning:
lto-wrapper: warning: using serial compilation of 2 LTRANS jobs
But, when the same program was compiled using v11.2 it produces zero number of errors and warnings.
My Questions:
What is the meaning of this warning?
How can I fix this?
Is this warning occurred due to upgrading gcc version to v12.1
Here's the g++ configuration on my machine:
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-werror --with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.1.0 (GCC)
Apparently that is a recent change in the -flto option. With a little bit of variation in the google search I was able to find this mail conversation:
Likewise if people just use -flto and auto-detection
finds nothing:
warning: using serial compilation of N LTRANS jobs
note: refer to http://.... for how to use parallel compile
[...]
That is, teach users rather than second-guessing and eventually
blowing things up. IMHO only the jobserver mode is safe to
automatically use.
So this is about using the -flto options correctly. I could not manage to easily get a GCC 12 on my system and thus could not try it myself, but you can try -flto=1 or -flto=auto to get rid of the warning.
Anyway it seems that this warning is rather harmless. It just tells you that GCC uses 2 threads in parallel to do the link time optimization.
The exact semantics and effects of the -flto is (together with the other optimization options) described in detail in the GCC manual. By the way you should not spam optimization options like you do in your command line. For example specifying multiple -O... options will only have the effect of the last one of them. Unless you know exactly what you are doing and have carefully read the manual, just stick to use -O3 and you will be fine.

Filesystem c++, geting no output. Avoiding static compiling? [duplicate]

I'm trying to get a program using the <filesystem> library running on Windows. I'm using MSYS2's (64 Bit) g++.
#include <iostream>
#include <filesystem>
int main()
{
std::cout << "Hello World\n";
std::cout << "Current path is " << std::filesystem::current_path() << '\n';
}
I'm building it with
g++ -std=c++17 -Wall -Werror -Wextra main.cpp -lstdc++fs
I get no console output from the compiler. It silently generates an a.exe. Executing the a.exe just does nothing. There is no output and no errors. $? (which is said to contain a program's return code) is 127 after running the program.
g++ -v prints:
Using built-in specs.
COLLECT_GCC=C:\msys64\mingw64\bin\g++.exe
COLLECT_LTO_WRAPPER=C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.1.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-9.1.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64 --with-tune=generic --enable-languages=c,lto,c++,fortran,ada,objc,obj-c++ --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts=yes --enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --enable-plugin --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev3, Built by MSYS2 project' --with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld
Thread model: posix
gcc version 9.1.0 (Rev3, Built by MSYS2 project)
What could be wrong?
(I get a Hello World output and $? is 0, if I comment out the line with the std::filesystem::current_path() call, so the compiler is working.)
Thanks to the commenters for dropping some ideas that finally led me to finding a solution.
TL;DR
If you have various MinGW-based tool sets installed (e.g. Cygwin, MinGW, MSYS, Git Bash), use the shell shipped with the set. Only carefully add the mingw*/bin paths to PATH; rather stick to the default PATH setup of the respective shell. Click here, if you want to have convenient context menu shortcuts for the MSYS shell.
A Story about a million MinGWs
The problem was due to my weird local setup. Over the time I accumulated various versions of MinGW spread all over my computer. If I needed a utility, say diff, I would google it and download something from somewhere (often sourceforge), install it to somewhere and add the bin folder to my PATH. This strategy worked for most things.
Toolsets I've installed over the time, including but not restricted to:
MinGW (32 and 64)
Cygwin
MSYS
Git (+ Git Bash)
For some long time now I have mostly been using the Git Bash for everything. Lately I wanted to get the newest g++ compiler and stuff and found that MSYS2 has a package manager (pacman) and pretty up to date packages so I installed it. And added it to the PATH, then used the Git Bash.
However, each toolset coming with its own shell does its own PATH magic and has its own MinGW copy. So I made my Git Bash use the MSYS2 g++, but applications executed from the Git Bash still used DLLs from Git Bash's MinGW copy. I don't know for sure, but I think it's very probably that this was the problem.
For finding out, I used the following in the Git Bash:
# because of my PATH adjustment, I got the right g++
$ which g++
/c/msys64/mingw64/bin/g++
# my program uses DLLs from /mingw64, though
$ ldd a.exe
ntdll.dll => /c/Windows/SYSTEM32/ntdll.dll (0x77060000)
kernel32.dll => /c/Windows/system32/kernel32.dll (0x76e40000)
KERNELBASE.dll => /c/Windows/system32/KERNELBASE.dll (0x7fefcc00000)
msvcrt.dll => /c/Windows/system32/msvcrt.dll (0x7fefcf70000)
libgcc_s_seh-1.dll => /mingw64/bin/libgcc_s_seh-1.dll (0x61440000)
libwinpthread-1.dll => /mingw64/bin/libwinpthread-1.dll (0x64940000)
libstdc++-6.dll => /mingw64/bin/libstdc++-6.dll (0x6fc40000)
USER32.dll => /c/Windows/system32/USER32.dll (0x76f60000)
GDI32.dll => /c/Windows/system32/GDI32.dll (0x7fefddb0000)
LPK.dll => /c/Windows/system32/LPK.dll (0x7fefd540000)
USP10.dll => /c/Windows/system32/USP10.dll (0x7fefdbe0000)
# with cygpath I can find out that this is actually the Git Bash's installation
$ cygpath -w /mingw64
C:\Program Files\Git\mingw64
MSYS2 comes with its own shell, which sets up its PATH correctly so the application works. In the MSYS2 shell:
$ ./a.exe
Hello World
Current path is "E:\\temporary\\2019_07_25-gpp_filesystem_test"
For the unlikely event someone got into a similar trouble and would like to use the MSYS2 shell more easily in various folders, check out this repo with a reg script setting up convenient context menu shortcuts for the MSYS2 shell: https://github.com/njzhangyifei/msys2-mingw-shortcut-menus

SIGABRT on throwing and catching exceptions with GCC on Mac OS X

I'm currently working on proper error management in a C++ library I'm maintaining. When writing a unit test for some negative cases (i. e. testing the proper throwing of exceptions), the unit test suite simply aborted with SIGABRT. I went on a hunt and tried to boil down the error with simpler exceptions being thrown and experimenting with various catch statements. But even a catch-all block could not prevent the crash (for a MWE see below).
My setup is this: I'm working on a Mac with the most current OS X Big Sur 11.1 with the latest XCode Command Line Tools installed. I'm using GCC from Homebrew, currently v10.2.0_1.
$ g++-10 -v
Using built-in specs.
COLLECT_GCC=g++-10
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/10.2.0_1/libexec/gcc/x86_64-apple-darwin20/10.2.0/lto-wrapper
Target: x86_64-apple-darwin20
Configured with: ../configure --build=x86_64-apple-darwin20 --prefix=/usr/local/Cellar/gcc/10.2.0_1 --libdir=/usr/local/Cellar/gcc/10.2.0_1/lib/gcc/10 --disable-nls --enable-checking=release --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-10 --with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl --with-system-zlib --with-pkgversion='Homebrew GCC 10.2.0_1' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues --disable-multilib --with-native-system-header-dir=/usr/include --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk SED=/usr/bin/sed
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (Homebrew GCC 10.2.0_1)
I also compiled GCC myself using Apples system toolchain. The output of the self-compiled GCC is this:
$ /opt/gcc/10.2.0/bin/g++-10 -v
Using built-in specs.
COLLECT_GCC=/opt/gcc/10.2.0/bin/g++-10
COLLECT_LTO_WRAPPER=/opt/gcc/10.2.0/libexec/gcc/x86_64-apple-darwin20/10.2.0/lto-wrapper
Target: x86_64-apple-darwin20
Configured with: ../configure --build=x86_64-apple-darwin20 --prefix=/opt/gcc/10.2.0 --libdir=/opt/gcc/10.2.0/lib/gcc/10 --disable-nls --enable-checking=release --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-10 --with-system-zlib --disable-multilib --with-native-system-header-dir=/usr/include --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk SED=/usr/bin/sed
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (GCC)
The result is still the same: exceptions abort the program.
My minimum working example is this:
#include <iostream>
#include <stdexcept>
int main()
{
try {
throw "this is an exception text";
}
catch(const char* e)
{
std::cerr << e << std::endl;
}
catch(...)
{
std::cerr << "Unknown error!" << std::endl;
}
return 0;
}
This compiles fine and produces the expected output on my Linux VM.
I'm using the following commands to compile it on my Mac:
$ g++-10 -o bin/main.o -c -std=c++11 main.cpp
$ g++-10 -o bin/main bin/main.o
$ ./bin/main
[1] 60310 abort ./bin/main
Using LLDB yields:
(lldb) run
Process 61177 launched: './bin/main' (x86_64)
Process 61177 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
frame #0: 0x00007fff202fa462 libsystem_kernel.dylib`__pthread_kill + 10
libsystem_kernel.dylib`__pthread_kill:
-> 0x7fff202fa462 <+10>: jae 0x7fff202fa46c ; <+20>
0x7fff202fa464 <+12>: movq %rax, %rdi
0x7fff202fa467 <+15>: jmp 0x7fff202f46a1 ; cerror_nocancel
0x7fff202fa46c <+20>: retq
Target 0: (main) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
* frame #0: 0x00007fff202fa462 libsystem_kernel.dylib`__pthread_kill + 10
frame #1: 0x00007fff20328610 libsystem_pthread.dylib`pthread_kill + 263
frame #2: 0x00007fff2027b720 libsystem_c.dylib`abort + 120
frame #3: 0x000000010048b00a libgcc_s.1.dylib`uw_init_context_1.cold + 5
frame #4: 0x0000000100488475 libgcc_s.1.dylib`_Unwind_RaiseException + 69
frame #5: 0x00000001001382f7 libstdc++.6.dylib`__cxa_throw + 55
frame #6: 0x0000000100003d55 main`main + 52
frame #7: 0x00007fff20343621 libdyld.dylib`start + 1
It seems to me as if another error happens during the unwind phase which then leads to the termination. Which would also explain, why no catch block is ever reached.
This is way out of my realm of expertise, so any ideas are welcome.
Edit: Updated question after the latest GCC Homebrew release.
I confirm the unexpected behaviour on Big Sur, Homebrew GCC 10.2.0_2 setup. Changing the linked brew libstdc++ to the system one (assuming the one found in /usr/lib is installed by macOS) solved the problem on my setup:
$ g++-10 main.cpp -o main -std=c++11
$ ./main
Abort trap: 6
$ otool -L main
main:
/usr/local/opt/gcc/lib/gcc/10/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.28.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.60.1)
/usr/local/lib/gcc/10/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
$ install_name_tool -change /usr/local/opt/gcc/lib/gcc/10/libstdc++.6.dylib /usr/lib/libstdc++.6.dylib main
$ ./main
this is an exception text
Alternatively, setting export DYLD_LIBRARY_PATH=/usr/lib before running main has the same effect.
Update: The bug has been fixed and the patch is included in brew's gcc-10.2.0_3.

C++ multithreading errors

I have been starting to try and learn how to utilize multithreading in c++, but the #include<thread> causes issues with the thread type being not declared in the scope. error: 'thread' was not declared in this scope. I have been doing research, and I have come across a lot of answers regarding how to solve this issue. Im presently at the understanding that my compiler, MinGW, doesn't support thread effectively, but I am not sure what to do with that information.
Any guidance on this matter is appreciated.
Also, I think this may be helpful. If I run gcc -v on my command line, I get this output:
Using built-in specs.
COLLECT_GCC=c:\MinGW\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/6.3.0/lto-wrapper.exe
Target: mingw32
Configured with: ../src/gcc-6.3.0/configure --build=x86_64-pc-linux-gnu --host=mingw32 --target=mingw32 --with-gmp=/mingw --with-mpfr --with-mpc=/mingw --with-isl=/mingw --prefix=/mingw --disable-win32-registry --with-arch=i586 --with-tune=generic --enable-languages=c,c++,objc,obj-c++,fortran,ada --with-pkgversion='MinGW.org GCC-6.3.0-1' --enable-static --enable-shared --enable-threads --with-dwarf2 --disable-sjlj-exceptions --enable-version-specific-runtime-libs --with-libiconv-prefix=/mingw --with-libintl-prefix=/mingw --enable-libstdcxx-debug --enable-libgomp --disable-libvtv --enable-nls
Thread model: win32
gcc version 6.3.0 (MinGW.org GCC-6.3.0-1)
edit: I've seen this webpage, https://github.com/meganz/mingw-std-threads, as a potential solution, but I don't think this works for me. Unless somehow I am putting the mingw-thread.h in the wrong folder.
I think the problem here is you did not tell the compiler using c++11 features. 'thread' is belonged to c++11 features, let try adding -std=c++11 into CXXFLAGS or CPPFLAGS and see if it resolves your problem
My psychic powers suggest your forgot the std:: namespace attribute. That would explain why thread is undefined, even with #include <thread>. The other answer about -std=c++11 is also steering you into the right direction. And don't forget the -pthread compiler/linker option.
$ cat foo.cpp
#include <thread>
#include <iostream>
void threadfunc()
{
std::cout << "Hello from the worker thread" << std::endl;
}
int main()
{
std::thread t(threadfunc);
t.join();
return 0;
}
$ g++ foo.cpp -std=c++11 -o foo -pthread
$ ./foo
Hello from the worker thread

Why GCC 8.2 compilation throwing errors during soft floating point sources?

When I am compiling gcc 8.2 on RHEL 6 (x86-64 arch) I am running into below issue
../../../libgcc/soft-fp/fixtfti.c:33:1: error: unknown type name 'TItype'; did you mean 'TFtype'?
TItype
^~~~~~
TFtype
../../../libgcc/soft-fp/fixtfti.c: In function '__fixtfti':
../../../libgcc/soft-fp/fixtfti.c:38:3: error: unknown type name 'UTItype'; did you mean 'UDItype'?
UTItype r;
^~~~~~~
UDItype
I compiled dependent gmp/mpfr/mpc/binutils/isl successfully and using them in my GCC compilation.
GCC configure command used:
../configure --prefix=/home/zk46w9e/apps/gcc-8.2.0-compliant/compiler/gcc-8.2/ --enable-gold --enable-libssp --enable-vtable-verify --enable-host-shared --enable-lto --with-mpc=/home/zk46w9e/apps/gcc-8.2.0-compliant/mpc/mpc-1.1.0 --with-mpfr=/home/zk46w9e/apps/gcc-8.2.0-compliant/mpfr/mpfr-4.0.1 --with-gmp=/home/zk46w9e/apps/gcc-8.2.0-compliant/gmp/gmp-6.1.2 --with-isl=/home/zk46w9e/apps/gcc-8.2.0-compliant/isl/isl-0.19 --enable-languages=c++ --disable-multilib --disable-nls --enable-threads=posix --enable-tls --enable-__cxa_atexit --enable-plugins
Still running into above issue. Can somebody throw some light?
I tried to compile GCC 32 bit , 64 bit individually by passing flags like -m32 etc which caused above error.
After passing --with-multilib-list=m32,m64 as option for GCC configure and reran the compilation, compilation went fine without any issues
thank you newkid for help