Consider this simple program:
#include <string>
#include <iostream>
#define BOOST_TEST_DYN_LINK
#define BOOST_TEST_MODULE "MyTest"
#include <boost/test/unit_test.hpp>
using namespace std;
template<char* S>
void Test()
{
BOOST_REQUIRE("Boom!" != string(S));
}
char bang[] = "Bang!";
BOOST_AUTO_TEST_CASE(Boom)
{
char boom[] = "Boom!";
Test<bang>();
}
I'm on Mac OS X v10.8.2 (Mountain Lion) and have XCode 4.5 installed.
The program works when compiled with GCC, for example,
gcc test.cpp -lboost_unit_test_framework-mt -lstdc++
but it crashes when compiled with Apple Clang 4.1 (tags/Apple/clang-421.11.65) (based on LLVM 3.1svn)
clang -std=c++11 -stdlib=libc++ -lc++ test.cpp -lboost_unit_test_framework-mt
I'm using Boost 1.51.0, installed using BREW. Recompiling Boost using Clang does not help.
Is there a solution to this mystery?
./a.out
Running 1 test case...
*** No errors detected
Segmentation fault: 11
gdb ./a.out
GNU gdb 6.3.50-20050815 (Apple version gdb-1822) (Sun Aug 5 03:00:42 UTC 2012)
...
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries .... done
(gdb) r
Starting program: /private/tmp/xx/a.out
Reading symbols for shared libraries +++............................. done
Running 1 test case...
*** No errors detected
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
0x0000000100056c56 in boost::unit_test::test_unit::~test_unit ()
(gdb) where
#0 0x0000000100056c56 in boost::unit_test::test_unit::~test_unit ()
#1 0x000000010002435f in boost::unit_test::master_test_suite_t::~master_test_suite_t ()
#2 0x00000001000244dd in boost::unit_test::framework_impl::~framework_impl ()
#3 0x00007fff96179307 in __cxa_finalize ()
#4 0x00007fff9617af57 in exit ()
#5 0x00007fff944897e8 in start ()
lldb a.out
Current executable set to 'a.out' (x86_64).
(lldb) r
Process 71553 launched: '/private/tmp/xx/a.out' (x86_64)
Running 1 test case...
*** No errors detected
Process 71553 stopped
* thread #1: tid = 0x1c03, 0x0000000100056c56 libboost_unit_test_framework.dylib`boost::unit_test::test_unit::~test_unit() + 86, stop reason = EXC_BAD_ACCESS (code=13, address=0x0)
frame #0: 0x0000000100056c56 libboost_unit_test_framework.dylib`boost::unit_test::test_unit::~test_unit() + 86
libboost_unit_test_framework.dylib`boost::unit_test::test_unit::~test_unit() + 86:
-> 0x100056c56: lock
0x100056c57: xaddl %ecx, -8(%rax)
0x100056c5b: testl %ecx, %ecx
0x100056c5d: jg 0x100056c68 ; boost::unit_test::test_unit::~test_unit() + 104
clang --version
Apple clang version 4.1 (tags/Apple/clang-421.11.65) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin12.2.0
Thread model: posix
Recompiling Boost with the C++11 options does the trick.
./bootstrap.sh --with-toolset=clang --prefix=/usr/local
sudo ./b2 install toolset=clang cxxflags="-std=c++11 -stdlib=libc++" linkflags="-stdlib=libc++" threading=multi
I made a mistake of using just ./b2 install last time but the install step appears to build some libraries before installing them.
I had the same issue than timlukins.
I had to do cmake .. -DBoost_USE_STATIC_LIBS=YES. But as I had other issues compiling with boost_timer for instance, I found that it was my include that was not correct.
I had to replace :
#include <boost/test/included/unit_test.hpp>
with:
#include <boost/test/unit_test.hpp>
It was working fine with gcc and VS13, but not with clang.
If it can help...
The following seems to work, but you may need the other arguments.
USER (~/tmp)
$ clang++ -pedantic test.cpp -lboost_unit_test_framework-mt
USER (~/tmp)
$ ./a.out
Running 1 test case...
*** No errors detected
Related
I am tying to launch a debugging of clang code via lldb. I'm using a WSL Ubuntu 20.04 LTS. I installed a clang and lldb via sudo apt-get install clang and sudo apt-get install lldb accordingly.
The test code (mytest.cpp) is the following:
#include <iostream>
int main()
{
std::cout << "TEST" << std::endl;
return 0;
}
Compilation command: clang++ -g -std=c++17 -o mytest mytest.cpp
Then I calling a debugger:
lldb mytest
(lldb) target create "mytest"
Current executable set to '/home/adzol/Projects/mytest' (x86_64).
(lldb) r
Process 51 launched: '/home/adzol/Projects/mytest' (x86_64)
And that's it. Nothing is happening. What can be wrong here?
But if I am calling my executable file directly, I am getting expected console output:
./mytest
TEST
I found out that the problem was is WSL 1. I updated my WSL to WSL 2 and this all works.
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.
I have been having some trouble getting my gcc and g++ compiler to work on my
mac (OSX Yosemite 10.10.2).
I have written up a simple "Hello World" program and even these seem to not
work. The two program that I tried to run are
hello.c
#include <stdio.h>
int main()
{
printf("Hello world\n");
return 0;
}
hello.cpp
#include <iostream>
int main()
{
std::cout << "Hello World";
}
I can compile the C program using cc hello.c and everything works fine, but
when I do gcc hello.c I get this error
[1] 38508 segmentation fault gcc hello.c
I get a similar error attempting to compile my C++ code
[1] 38596 segmentation fault g++ hello.cpp
I did which gcc and I get /opt/local/bin/gcc and that directory is in my
path.
( /usr/texbin /opt/local/bin /opt/local/sbin /bin /usr/sbin /sbin /usr/local/bin/usr/bin )
So I am confused as to what is happening. I thought I downloaded all of the
Xcode things that I needed. I would like to get gcc and g++ running
properly. I hope that you can help.
Thanks!
It seems that gcc and g++ have to be installed/added to the MAC os.
From your description, I would expect that the wrong version of those tools was installed.
This answer should help.
Be sure to read all the answers to the question before proceeding with a gcc installation.
I had a similar problem where even gcc --versionwas giving me a "Segmentation fault: 11". This is on OSX 10.10.5 with XCode 6.4. After much googling and no solution, I found that clang (Apple's LLVM-based C compiler) is intended to be a compatible replacement for gcc, so I just sym-linked gcc to clang as follows:
whence gcc #=> /usr/local/bin/gcc
whence clang #=> /usr/bin/clang
cd /usr/local/bin
sudo mv gcc gcc_OLD
sudo ln -s /usr/bin/clang /usr/local/bin/gcc
gcc -v
Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.5.0
Thread model: posix
Now I am able to successfully compile c-language stuff, like my ruby extensions.
I have recently installed gcc from http://hpc.sourceforge.net/ and while everything else works fine whenever I try to include cmath in the header it is showing the following error:
/usr/local/lib/gcc/x86_64-apple-darwin13.4.0/5.0.0/include-fixed/math.h:273:5: internal compiler error: Illegal instruction: 4
return __inline_isfinitef(__x) && __builtin_fabsf(__x) >= __FLT_MIN__;
^
/usr/local/lib/gcc/x86_64-apple-darwin13.4.0/5.0.0/include-fixed/math.h:273:5: internal compiler error: Abort trap: 6
g++: internal compiler error: Abort trap: 6 (program cc1plus)
Abort trap: 6
I'm using OSX Yosemite and on typing gcc -v it shows the following:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin13.4.0/5.0.0/lto-wrapper
Target: x86_64-apple-darwin13.4.0
Configured with: ../gcc-5-20140928/configure --enable-languages=c++,fortran
Thread model: posix
gcc version 5.0.0 20140928 (experimental) (GCC)
Thanks in advance for your time.
This can happen when the GMP library was compiled for CPU which provides instructions not available on the runtime CPU, see gmp CPU identification
I'm trying to use C++11 (with Clang and libc++ on OS X) for a program, but whenever I debug with gdb and try to inspect standard containers, gdb segfaults. Here's a minimal example:
file.cpp:
#include <iostream>
#include <string>
int main(int argc, char* argv[])
{
std::string str = "Hello world";
std::cout << str << std::endl; // Breakpoint here
}
If I compile for C++11 using the following:
$ c++ --version
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.4.0
Thread model: posix
$
$ c++ -ggdb -std=c++11 -stdlib=libc++ -Wall -pedantic -O0 -c file.cpp
$ c++ -ggdb -std=c++11 -stdlib=libc++ -Wall -pedantic -O0 file.o -o program
And then debug as follows, it crashes when I try to p str.size():
$ gdb program
GNU gdb 6.3.50-20050815 (Apple version gdb-1824) (Wed Feb 6 22:51:23 UTC 2013)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries ... done
(gdb) br file.cpp:8
Breakpoint 1 at 0x100000d80: file file.cpp, line 8.
(gdb) run
Starting program: /Users/mjbshaw/School/cs6640/2/program
Reading symbols for shared libraries ++............................. done
Breakpoint 1, main (argc=1, argv=0x7fff5fbffab0) at file.cpp:8
8 std::cout << str << std::endl; // Breakpoint here
(gdb) p str.size()
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
std::__1::operator<< <char, std::__1::char_traits<char>, std::__1::allocator<char> > (__os=#0x7fff5fc3d628, __str=#0x1) at string:1243
1243
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on"
Evaluation of the expression containing the function (std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__is_long() const) will be abandoned.
If I don't run this in gdb, I get no crash and it works fine (but I need gdb to debug my program). Also, if I remove -std=c++11 -stdlib=libc++ from the compiling options, then it works fine (even in gdb), but I need C++11 for my program.
Are there some known issues with gdb and C++11 (specifically libc++)? I know libc++ and libstdc++ can cause issues if used together, but I'm not trying to use them together (at least not consciously; all I want to use is libc++). Am I specifying some compilation options wrong? Is there a way to properly compile for C++11 on OS X and still be able to debug properly?
GDB 6.3 is almost nine years old. That's just about eternity in Internet years. The product has improved greatly since then. Updating to the last stable release is a must for every developer.