I'm building a simple utility program that queries a mysql database, and uses regex to isolate strings in the table data.
I'm using MariaDB c++/connector, and the latest versions of MariaDB. The code was copied from the MariaDB website. I have simplified the software to illustrate the problem. See below:
// g++ -o mariadb_connect mariadb_connect.cpp -lmariadbcpp
// From https://mariadb.com/docs/clients/connector-cpp/
// with three additional lines that cause segfault
#include <iostream>
#include <mariadb/conncpp.hpp>
#include <regex> // <-- Added to the example
int main()
{
try
{
// Instantiate Driver
sql::Driver* driver = sql::mariadb::get_driver_instance();
// Configure Connection
// The URL or TCP connection string format is
// ``jdbc:mariadb://host:port/database``.
sql::SQLString url("jdbc:mariadb://localhost:3306/??????");
// Use a properties map for the user name and password
sql::Properties properties({
{"user", "???????"},
{"password", "????????"}
});
// Establish Connection
// Use a smart pointer for extra safety
std::unique_ptr<sql::Connection> conn(driver->connect(url, properties));
// Use Connection
std::cout << "Using the connection" << std::endl; // <-- Added
std::regex regexp("(faststatic.com)(.*)"); // <-- Added (Causes segfault)
// Close Connection
conn->close();
}
// Catch Exceptions
catch (sql::SQLException& e)
{
std::cout << "Error Connecting to MariaDB Platform: "
<< e.what() << std::endl;
// Exit (Failed)
return 1;
}
// Exit (Success)
return 0;
}
(???? used for private data)
Compiled with g++ on an AWS EC2 instance running Amazon Linux 2 AMI.
Compiles fine and runs fine until I added the std::regex regexp(...)
line. It still compiles fine with the addition, but on execution calls
a segfault.
I have used gdb which provides the following output with breakpoint set
to main.
(gdb) b main
Breakpoint 1 at 0x40404b: file mariadb_connect.cpp, line 15.
(gdb) run
Starting program: /home/msellers/proj/preload_images/spike/mariadb_connect
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
0x000000000064a588 in ?? ()
Here is the output of the gdb bt command after the segfault:
(gdb) bt
#0 0x000000000064a588 in ?? ()
#1 0x0000000000409155 in std::__detail::_Scanner<char>::_M_scan_normal (this=0x7fffffffe018) at /usr/include/c++/7/bits/regex_scanner.tcc:119
#2 0x00000000004084a1 in std::__detail::_Scanner<char>::_M_advance (this=0x7fffffffe018) at /usr/include/c++/7/bits/regex_scanner.tcc:80
#3 0x00007ffff7c3e060 in std::__detail::_Compiler<std::regex_traits<char> >::_M_match_token (this=this#entry=0x7fffffffe000, token=std::__detail::_ScannerBase::_S_token_subexpr_begin) at /usr/local/include/c++/4.9.4/bits/regex_compiler.tcc:541
#4 0x00007ffff7c513a2 in std::__detail::_Compiler<std::regex_traits<char> >::_M_match_token (token=std::__detail::_ScannerBase::_S_token_subexpr_begin, this=0x7fffffffe000) at /usr/local/include/c++/4.9.4/bits/regex_compiler.tcc:316
#5 std::__detail::_Compiler<std::regex_traits<char> >::_M_atom (this=this#entry=0x7fffffffe000) at /usr/local/include/c++/4.9.4/bits/regex_compiler.tcc:326
#6 0x00007ffff7c515b0 in std::__detail::_Compiler<std::regex_traits<char> >::_M_term (this=0x7fffffffe000) at /usr/local/include/c++/4.9.4/bits/regex_compiler.tcc:136
#7 std::__detail::_Compiler<std::regex_traits<char> >::_M_alternative (this=0x7fffffffe000) at /usr/local/include/c++/4.9.4/bits/regex_compiler.tcc:118
#8 0x00007ffff7c51809 in std::__detail::_Compiler<std::regex_traits<char> >::_M_disjunction (this=this#entry=0x7fffffffe000) at /usr/local/include/c++/4.9.4/bits/regex_compiler.tcc:97
#9 0x00007ffff7c51e18 in std::__detail::_Compiler<std::regex_traits<char> >::_Compiler (this=0x7fffffffe000, __b=<optimized out>, __e=<optimized out>, __traits=..., __flags=<optimized out>)
at /usr/local/include/c++/4.9.4/bits/regex_compiler.tcc:82
#10 0x00007ffff7c5222d in std::__detail::__compile_nfa<std::regex_traits<char> > (__first=<optimized out>, __last=<optimized out>, __traits=..., __flags=<optimized out>) at /usr/local/include/c++/4.9.4/bits/regex_compiler.h:158
#11 0x00007ffff7c524da in std::basic_regex<char, std::regex_traits<char> >::basic_regex<char const*> (__f=<optimized out>, __last=<optimized out>, __first=<optimized out>, this=0x7ffff7dc2a40 <sql::mariadb::UrlParser::URL_PARAMETER>)
at /usr/local/include/c++/4.9.4/bits/regex.h:540
#12 std::basic_regex<char, std::regex_traits<char> >::basic_regex (this=0x7ffff7dc2a40 <sql::mariadb::UrlParser::URL_PARAMETER>, __p=<optimized out>, __f=<optimized out>) at /usr/local/include/c++/4.9.4/bits/regex.h:452
#13 0x00007ffff7c331ee in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /home/buildbot/src/src/UrlParser.cpp:34
#14 _GLOBAL__sub_I_UrlParser.cpp(void) () at /home/buildbot/src/src/UrlParser.cpp:444
#15 0x00007ffff7de7dc2 in call_init (l=<optimized out>, argc=argc#entry=1, argv=argv#entry=0x7fffffffe2b8, env=env#entry=0x7fffffffe2c8) at dl-init.c:72
#16 0x00007ffff7de7eb6 in call_init (env=0x7fffffffe2c8, argv=0x7fffffffe2b8, argc=1, l=<optimized out>) at dl-init.c:119
#17 _dl_init (main_map=0x7ffff7ffe130, argc=1, argv=0x7fffffffe2b8, env=0x7fffffffe2c8) at dl-init.c:120
#18 0x00007ffff7dd9f2a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#19 0x0000000000000001 in ?? ()
#20 0x00007fffffffe520 in ?? ()
#21 0x0000000000000000 in ?? ()
(gdb)
Does this help?
Mark
GCC version 7.3.1
In the backtrace, we see that the crash is happening in the GCC-7 regexp implementation:
#1 0x0000000000409155 in std::__detail::_Scanner<char>::_M_scan_normal (this=0x7fffffffe018) at /usr/include/c++/7/bits/regex_scanner.tcc:119
We also see that this crash is happening while some global inside (presumably1) MariaDB connector is being initialized, while using GCC-4.9.4 version of libstdc++:
#12 std::basic_regex<char, std::regex_traits<char> >::basic_regex (this=0x7ffff7dc2a40 <sql::mariadb::UrlParser::URL_PARAMETER>, __p=<optimized out>, __f=<optimized out>) at /usr/local/include/c++/4.9.4/bits/regex.h:452
#13 0x00007ffff7c331ee in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /home/buildbot/src/src/UrlParser.cpp:34
It is exceedingly likely that this 4.9.4 vs. 7.3.1 mismatch is the cause of the crash, and that either building the app with g++-4.9.4 or building the MariaDB with g++-7.3.1 will fix the problem.
In theory GCC version of libstdc++ should be backwards compatible, but verifying ABI compatibility in C++ is quite hard, and many mistakes have been made. Also, g++4.9.4 is ancient.
Another possible solution is to build the application with clang using libc++ -- this will avoid any possibility of symbol conflicts2.
1 You can verify whether frame #13 is really coming from the MariaDB by executing these GDB commands: frame 13, info symbol $pc.
2 To achieve this, you may need to explicitly tell clang to use libc++, as it may default to using libstdc++. Use clang++ -stdlib=libc++ ... to be sure. Documentation here.
Related
I have a Raspberry Pi 3B+ with my Qt code on it (Qt 5.12.5). When I run my code, it randomly crashes with a Bus Error after a few hours. I am not sure how to work out the exact cause. I cross compile on Ubuntu for the RPi using the latest Raspberry Pi OS (2020-05-27).
The core dump (I have replaced some irrelevant parts with ...)
pi#raspberrypi: $ gdb TEST core
GNU gdb (Raspbian 8.2.1-2) 8.2.1
...
Type "apropos word" to search for commands related to "word"...
Reading symbols from TEST...done.
[New LWP 1233]
...
[New LWP 1226]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Core was generated by `./TEST'.
Program terminated with signal SIGBUS, Bus error.
#0 0x755b5b7c in QString::arg(long long, int, int, QChar) const () from /usr/local/qt5pi/lib/libQt5Core.so.5
[Current thread is 1 (Thread 0x6feff440 (LWP 1233))]
(gdb) bt full
#0 0x755b5b7c in QString::arg(long long, int, int, QChar) const () at /usr/local/qt5pi/lib/libQt5Core.so.5
#1 0x0001c0bc in QString::arg(int, int, int, QChar) const (this=0x6fefdc78, a=12, fieldWidth=0, base=10, fillChar=...) at ../raspi/qt5pi/include/QtCore/qstring.h:976
#2 0x00039ff8 in StageState::getStateString() (this=0x6fefdf00) at ../TEST/stage.h:35
...
#7 0x00142124 in TEST::timerExpired() (this=0x7ecd4708) at ../TEST/TEST.cpp:51
__PRETTY_FUNCTION__ = "void TEST::timerExpired()"
locker = {val = 2127384345}
#8 0x0015c188 in TEST::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (_o=0x7ecd4708, _c=QMetaObject::InvokeMetaMethod, _id=2, _a=0x6fefe9d8) at moc_TEST.cpp:122
_t = 0x7ecd4708
#9 0x75722b08 in QMetaObject::activate(QObject*, int, int, void**) () at /usr/local/qt5pi/lib/libQt5Core.so.5
#10 0x75730c1c in QTimer::timeout(QTimer::QPrivateSignal) () at /usr/local/qt5pi/lib/libQt5Core.so.5
#11 0x75730fc8 in QTimer::timerEvent(QTimerEvent*) () at /usr/local/qt5pi/lib/libQt5Core.so.5
#12 0x75724194 in QObject::event(QEvent*) () at /usr/local/qt5pi/lib/libQt5Core.so.5
#13 0x768c6b88 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/local/qt5pi/lib/libQt5Widgets.so.5
#14 0x768ce29c in QApplication::notify(QObject*, QEvent*) () at /usr/local/qt5pi/lib/libQt5Widgets.so.5
#15 0x759b62ec in QCoreApplication::self () at /usr/local/qt5pi/lib/libQt5Core.so.5
(gdb)
../TEST/stage.h:35 refers to this code:
return QString("text %1").arg(aInt);
Possible causes and fixes I am considering:
To me, from the stack trace, it looks like the crashes are occurring inside QString, possibly due to a Qt bug? However I am not sure. I can try a newer version of Qt.
I am also using a QTimer in a thread, maybe this could cause a issue, accessing a object from other threads? I am already using QMutex. I could instead only use the gui thread short term and test if crashes still occur.
Searching online, I found a comment to look a the dmesg output (below), maybe my MicroSD card is dying? I am waiting for a new one to arrive.
Anything else?
pi#raspberrypi:~ $ dmesg
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 5.4.44-v7+ (dom#buildbot) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1320 SMP Wed Jun 3 16:07:06 BST 2020
[ 0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d
...
[ 17.898294] Bluetooth: BNEP filters: protocol multicast
[ 17.898313] Bluetooth: BNEP socket layer initialized
[16092.809350] Alignment trap: not handling instruction e1903f9f at [<755b5b78>]
[16092.809367] 8<--- cut here ---
[16092.815191] Unhandled fault: alignment exception (0x001) at 0x6f577277
[16092.820865] pgd = 6aa8fcbe
[16092.826468] [6f577277] *pgd=3278c835, *pte=2812175f, *ppte=28121c7f
Here is another bus error that is similar but not quite the same as previously:
pi#raspberrypi:~/TEST/bin $ gdb TEST core
GNU gdb (Raspbian 8.2.1-2) 8.2.1
...
Type "apropos word" to search for commands related to "word"...
Reading symbols from TEST...done.
[New LWP 767]
...
[New LWP 763]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Core was generated by `./TEST'.
Program terminated with signal SIGBUS, Bus error.
#0 0x7568d470 in QString::fromAscii_helper(char const*, int) () from /usr/local/qt5pi/lib/libQt5Core.so.5
[Current thread is 1 (Thread 0x709bf440 (LWP 767))]
(gdb) bt
#0 0x7568d470 in QString::fromAscii_helper(char const*, int) () at /usr/local/qt5pi/lib/libQt5Core.so.5
#1 0x75830da4 in () at /usr/local/qt5pi/lib/libQt5Core.so.5
#2 0x0001c030 in QString::QString(char const*) (this=0x709be71c, ch=0x15fa88 "[0-9| ]{3}") at ../raspi/qt5pi/include/QtCore/qstring.h:700
#3 0x00029da8 in Measurement::doesRececivedDataFormatMatchRegex(QString) (this=0x709be7f4, receivedData=...) at ../TEST/Measurement.h:103
...
#12 0x7580c58c in QSocketNotifier::activated(int, QSocketNotifier::QPrivateSignal) () at /usr/local/qt5pi/lib/libQt5Core.so.5
#13 0x7580c90c in QSocketNotifier::event(QEvent*) () at /usr/local/qt5pi/lib/libQt5Core.so.5
#14 0x769a2b88 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/local/qt5pi/lib/libQt5Widgets.so.5
#15 0x769aa29c in QApplication::notify(QObject*, QEvent*) () at /usr/local/qt5pi/lib/libQt5Widgets.so.5
#16 0x75a922ec in QCoreApplication::self () at /usr/local/qt5pi/lib/libQt5Core.so.5
Edit: added getStateString() and doesRececivedDataFormatMatchRegex() functions
QString getStateString() {
switch (state) {
case StageState::AEnum:
return QString("text %1").arg(aInt);
...
default:
return QString("Unknown");
}
}
bool Measurement::doesRececivedDataFormatMatchRegex(QString receivedData)
{
QRegExp regExp("[0-9| ]{3}");
return receivedData.indexOf(regExp) != -1;
}
I am building a custom protoc-compiler that is based on googles c++ libraries for protobuf.
I ran into a strange error when running it on linux, while it runs fine on MacOS
terminate called after throwing an instance of 'std::system_error'
what(): Unknown error -1
After setting up and trying around with my debugger this is the stacktrace:
#1 0x00007f61c097b897 in abort () from /usr/lib/libc.so.6
#2 0x00007f61c0d1381d in __gnu_cxx::__verbose_terminate_handler () at /build/gcc/src/gcc/libstdc++-v3/libsupc++/vterminate.cc:95
#3 0x00007f61c0d204da in __cxxabiv1::__terminate (handler=<optimized out>) at /build/gcc/src/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:47
#4 0x00007f61c0d20537 in std::terminate () at /build/gcc/src/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:57
#5 0x00007f61c0d2078e in __cxxabiv1::__cxa_throw (obj=obj#entry=0x5568aec89df0, tinfo=tinfo#entry=0x7f61c0e5a750 <typeinfo for std::system_error>, dest=dest#entry=0x7f61c0d4cc60 <std::system_error::~system_error()>) at /build/gcc/src/gcc/libstdc++-v3/libsupc++/eh_throw.cc:95
#6 0x00007f61c0d167ff in std::__throw_system_error (__i=-1) at /build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/ext/new_allocator.h:89
#7 0x00007f61c14b5c63 in std::call_once<void (&)(google::protobuf::internal::DescriptorTable const*), google::protobuf::internal::DescriptorTable const*&> (__f=#0x7f61c14c0780: {void (const google::protobuf::internal::DescriptorTable *)} 0x7f61c14c0780 <google::protobuf::(anonymous namespace)::AssignDescriptorsImpl(google::protobuf::internal::DescriptorTable const*)>, __once=...) at /usr/include/c++/7/mutex:698
#8 google::protobuf::internal::AssignDescriptors (table=<optimized out>, table#entry=0x7f61c17dddc0 <descriptor_table_google_2fprotobuf_2fdescriptor_2eproto>) at google/protobuf/generated_message_reflection.cc:2407
#9 0x00007f61c148f440 in google::protobuf::FileDescriptorProto::GetMetadataStatic () at ./google/protobuf/descriptor.pb.h:623
#10 google::protobuf::FileDescriptorProto::GetMetadata (this=<optimized out>) at google/protobuf/descriptor.pb.cc:2281
#11 0x00005568acbb22ed in google::protobuf::Message::GetReflection (this=0x7ffd47e4efc0) at /home/leo/CLionProjects/protoc-gen-java-leo/protoc/include/google/protobuf/message.h:333
#12 0x00005568acbad61f in google::protobuf::compiler::java_leo::(anonymous namespace)::CollectExtensions (message=..., extensions=0x7ffd47e4eef0) at /home/leo/CLionProjects/protoc-gen-java-leo/src/google/protobuf/compiler/java_leo/java_file.cc:84
#13 0x00005568acbad8ca in google::protobuf::compiler::java_leo::(anonymous namespace)::CollectExtensions (file_proto=..., alternate_pool=..., extensions=0x7ffd47e4eef0, file_data="\n\021addressbook.proto\022\btutorial\032\037google/protobuf/timestamp.proto\032\roptions.proto\"\255\002\n\006Person\022\"\n\002id\030\001 \001(\tB\022\222\202\031\016java.util.UUIDR\002id\022\022\n\004name\030\002 \001(\tR\004name\022\020\n\003age\030\003 \001(\005R\003age\022\024\n\005email\030\004 \001(\tR\005email\022\064\n\006phones\030\005 \003(\v2\034.tutorial.Person.PhoneNumberR\006phones\022=\n\flast_updated\030\006 \001(\v2\032.google.protobuf.TimestampR\vlastUpdated\032N\n\vPhoneNumber\022\026\n\006number\030\001 \001(\tR\006number\022'\n\004type\030\002 \001(\016\062\023.tutorial.PhoneTypeR\004type\"7\n\vAddressBook\022(\n\006people\030\001 \003(\v2\020.tutorial.PersonR\006people*+\n\tPhoneType\022\n\n\006MOBILE\020\000\022\b\n\004HOME\020\001\022\b\n\004WORK\020\002B+\n\024com.example.tutorialB\021AddressBookProtosP\001b\006proto3") at /home/leo/CLionProjects/protoc-gen-java-leo/src/google/protobuf/compiler/java_leo/java_file.cc:122
#14 0x00005568acbaf23f in google::protobuf::compiler::java_leo::FileGenerator::GenerateDescriptorInitializationCodeForImmutable (this=0x5568aec7d590, printer=0x7ffd47e4f380) at /home/leo/CLionProjects/protoc-gen-java-leo/src/google/protobuf/compiler/java_leo/java_file.cc:439
#15 0x00005568acbaed2a in google::protobuf::compiler::java_leo::FileGenerator::Generate (this=0x5568aec7d590, printer=0x7ffd47e4f380) at /home/leo/CLionProjects/protoc-gen-java-leo/src/google/protobuf/compiler/java_leo/java_file.cc:351
#16 0x00005568acbb73ea in google::protobuf::compiler::java_leo::JavaGenerator::Generate (this=0x7ffd47e4f788, file=0x5568aec77500, parameter="", context=0x7ffd47e4f5f0, error=0x7ffd47e4f5d0) at /home/leo/CLionProjects/protoc-gen-java-leo/src/google/protobuf/compiler/java_leo/java_generator.cc:158
#17 0x00007f61c0f06fae in google::protobuf::compiler::CodeGenerator::GenerateAll (this=0x7ffd47e4f788, files=std::vector of length 2, capacity 2 = {...}, parameter="", generator_context=0x7ffd47e4f5f0, error=0x7ffd47e4f5d0) at google/protobuf/compiler/code_generator.cc:58
#18 0x00007f61c0f16733 in google::protobuf::compiler::GenerateCode (request=..., generator=..., response=response#entry=0x7ffd47e4f6a0, error_msg=error_msg#entry=0x7ffd47e4f680) at google/protobuf/compiler/plugin.cc:133
#19 0x00007f61c0f16b17 in google::protobuf::compiler::PluginMain (argc=<optimized out>, argv=0x7ffd47e4f8c8, generator=0x7ffd47e4f788) at google/protobuf/compiler/plugin.cc:169
#20 0x00005568acbe9ed5 in main (argc=1, argv=0x7ffd47e4f8c8) at /home/leo/CLionProjects/protoc-gen-java-leo/main.cpp:10
#21 0x00007f61c097d153 in __libc_start_main () from /usr/lib/libc.so.6
#22 0x00005568acb9598e in _start ()
Since I'm a total C++ noob, it took me around 8 hours trying stuff out and googleing around before I found out the reason, so I wanted to share it here for the next person that might run into this problem.
It turns out, that the "pthread"-library is required and it crashes while calling the "call_once"-method if it's not present. A better error-message would have been great, "what(): Unknown error -1" didn't help out a lot :D
All I did was to add this line in my CMakeLists.txt:
target_link_libraries(${CMAKE_PROJECT_NAME} pthread)
Now it runs like a charm :)
Hope this helps someone.
I am using C++ for a program retrieving informations about files. Among them, I want to find out the MIME type of a given file.
To do so I use libmagic as follow:
#include <iostream>
#include <string>
#include <magic.h>
void foo (std::string path)
{
magic_t magic;
magic = magic_open (MAGIC_MIME_TYPE);
magic_load(magic, NULL);
magic_compile(magic, NULL);
std::string filetype (magic_file(magic, path.c_str()));
magic_close(magic);
std::cout << filetype << std::endl;
}
int main(int argc, char *argv[])
{
std::string str = "test.cxx";
foo (str);
return 0;
}
Trying on a computer running on Debian Jessie with gcc 4.9.2 and glibc 2.19, it works just fine.
However, on another computer on arch linux with gcc 5.1.0 and glibc 2.21, I have the following at runtime:
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_S_construct null not valid
gdb gives me additional information:
Program received signal SIGABRT, Aborted.
0x00007ffff6fb1528 in raise () from /usr/lib/libc.so.6
#0 0x00007ffff6fb1528 in raise () from /usr/lib/libc.so.6
#1 0x00007ffff6fb293a in abort () from /usr/lib/libc.so.6
#2 0x00007ffff78c9b3d in __gnu_cxx::__verbose_terminate_handler ()
at /build/gcc/src/gcc-5-20150519/libstdc++-v3/libsupc++/vterminate.cc:95
#3 0x00007ffff78c7996 in __cxxabiv1::__terminate (handler=<optimized out>)
at /build/gcc/src/gcc-5-20150519/libstdc++-v3/libsupc++/eh_terminate.cc:47
#4 0x00007ffff78c79e1 in std::terminate ()
at /build/gcc/src/gcc-5-20150519/libstdc++-v3/libsupc++/eh_terminate.cc:57
#5 0x00007ffff78c7bf8 in __cxxabiv1::__cxa_throw (obj=0x613fb0,
tinfo=0x7ffff7baea78 <typeinfo for std::logic_error>,
dest=0x7ffff78dd040 <std::logic_error::~logic_error()>)
at /build/gcc/src/gcc-5-20150519/libstdc++-v3/libsupc++/eh_throw.cc:87
#6 0x00007ffff78f08bf in std::__throw_logic_error (
__s=__s#entry=0x7ffff7976100 "basic_string::_S_construct null not valid")
at /build/gcc/src/gcc-5-20150519/libstdc++-v3/src/c++11/functexcept.cc:74
#7 0x00007ffff790acef in std::string::_S_construct<char const*> (__beg=<optimized out>,
__end=<optimized out>, __a=...)
at /build/gcc/src/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:577
#8 0x00007ffff790b0e6 in _S_construct_aux<char const*> (__a=..., __end=<optimized out>,
__beg=0x0)
at /build/gcc/src/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.h:4136
#9 _S_construct<char const*> (__a=..., __end=<optimized out>, __beg=0x0)
at /build/gcc/src/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string---Type <return> to continue, or q <return> to quit---
.h:4157
#10 std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string (
this=0x7fffffffe980, __s=0x0, __a=...)
at /build/gcc/src/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:659
#11 0x0000000000400df3 in foo (path="test.cxx") at test.cxx:11
#12 0x0000000000400ece in main (argc=1, argv=0x7fffffffeae8) at test.cxx:21
So I'm not quite sure if I can solve my problem, or is there a possible bug coming from glibc or libmagic?
I'm having trouble using boost_threads with clang. The clang version is 3.6.0 and boost version is 1.55.0 from the new Ubuntu 15.04. Program that used to work with previous versions of clang now segfaults at startup. There is no problems when I use g++ instead.
Here is an example program to illustrate the point.
#include <iostream>
#include <boost/thread.hpp>
using namespace std;
void output() {
try {
int x = 0;
for (;;) {
boost::this_thread::sleep(boost::posix_time::milliseconds(100));
cerr << x++ << endl;
}
} catch (boost::thread_interrupted&) {}
}
int main(int argc, char* argv[]) {
try {
boost::thread output_worker(output);
boost::this_thread::sleep(boost::posix_time::milliseconds(1000));
output_worker.interrupt();
output_worker.join();
} catch (...) {
cerr << "Unexpected error!" << endl;
exit(1);
}
}
If I compile it with g++ it works, i.e.
g++ thread.cpp -lboost_thread -lboost_system
If I compile it with clang
clang++ thread.cpp -lboost_thread -lboost_system
I get a segfault with the gdb trace below
Starting program: /home/dejan/test/a.out
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7bd0580 in boost::exception_ptr boost::exception_detail::get_static_exception_object<boost::exception_detail::bad_alloc_>() ()
from /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.55.0
(gdb) bt
#0 0x00007ffff7bd0580 in boost::exception_ptr boost::exception_detail::get_static_exception_object<boost::exception_detail::bad_alloc_>() ()
from /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.55.0
#1 0x00007ffff7bcb16a in ?? () from /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.55.0
#2 0x00007ffff7de95ba in call_init (l=<optimized out>, argc=argc#entry=1, argv=argv#entry=0x7fffffffdf98, env=env#entry=0x7fffffffdfa8)
at dl-init.c:72
#3 0x00007ffff7de96cb in call_init (env=<optimized out>, argv=<optimized out>, argc=<optimized out>, l=<optimized out>) at dl-init.c:30
#4 _dl_init (main_map=0x7ffff7ffe188, argc=1, argv=0x7fffffffdf98, env=0x7fffffffdfa8) at dl-init.c:120
#5 0x00007ffff7dd9d0a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#6 0x0000000000000001 in ?? ()
#7 0x00007fffffffe2fe in ?? ()
#8 0x0000000000000000 in ?? ()
Am I doing something wrong?
Compiling using clang -std=c++11 makes boost change its internal implementation and actually solves the segmentation fault.
It is not an ideal solution, but it is the way I will be going with our code.
I'm debugging a process that runs really slow when is executed from gdb on Windows (mingw32), so I decided to run it until it crash without gdb, and then to attach the debugger. I've installed a signal handler for sigsegv that shows its pid and waits, so when I see the message I load gdb and use the "attach" command with that pid. The problem is that gdb shows me an useless backtrace at that point. Here's an example:
void my_sigsegv_handler(int) {
std::cerr << "Segmentation fault! pid=" << GetCurrentProcessId();
std::cin.get(); // wait for gdb
}
int main() {
signal(SIGSEGV,my_sigsegv_handler);
int *p = 0;
std::cout << *p; // boom!
}
Compiled with "mingw32-g++ -g -O0", output from gdb's command "bt" (after selecting the proper thread) is:
#0 0x764e73ea in ?? ()
#1 0x7646f489 in ?? ()
#2 0x75edc3b3 in ?? ()
#3 0x75edc2bc in ?? ()
#4 0x75edc472 in ?? ()
#5 0x00415502 in __gnu_cxx::stdio_sync_filebuf<char, std::char_traits<char> >::uflow() ()
#6 0x00434f32 in std::istream::get() ()
#7 0x004016d5 in my_sigsegv_handler () at C:\Users\usuario\zinjai\sin_titulo.cpp:8
#8 0x004010f9 in _gnu_exception_handler (exception_data=0x28fa88) at ../mingwrt-4.0.3-1-mingw32-src/src/libcrt/crt/crt1.c:137
#9 0x76469d57 in ?? ()
#10 0x77100727 in ?? ()
#11 0x770c9d45 in ?? ()
#12 0x00000000 in ?? ()
Notice that this example does not corrupt stack when generating the segfault. Actualy, I can debug it anyway, just continuing execution. If I press enter the signal handler finishes, returns to the place where it was generated (main function), and the problem is not solved, but this time gdb is there to catch it. But I'd like to now how does it really works.
If I use the same method in gnu/linux I can see what I want to see here:
#5 0x00007f6809bf349e in std::istream::get() () from /usr/lib64/libstdc++.so.6
#6 0x00000000004008cd in my_signal_handler () at /home/zaskar/.zinjai/sin_titulo.cpp:6
#7 <signal handler called>
#8 0x00000000004008f9 in main (argc=1, argv=0x7fffa0613108) at /home/zaskar/.zinjai/sin_titulo.cpp:11
So the question is, why gdb cannot show me the correct backtrace from withing the signal handler? Or what am I doing wrong? Is there any better way to solve it?