I have downloaded and installed the jsoncpp library. I then try to use the library in my own application:
#include <json/json.h>
void parseJson() {
Json::Reader reader;
}
int main(int argc, char ** argv) {
parseJson();
exit(0);
}
The program compiles and links fine, but it crashes with SIGSEGV when running. The gdb backtrace looks like this:
(gdb) bt
#0 0x0000003a560b7672 in __gnu_cxx::__exchange_and_add () from /usr/lib64/libstdc++.so.6
#1 0x00000000004031e9 in std::string::_Rep::_M_dispose (this=0xffffffffffffffe9, __a=#0x7fffbfe60e57)
at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/basic_string.h:232
#2 0x0000000000403236 in ~basic_string (this=0x7fffbfe60fb0)
at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/basic_string.h:478
#3 0x00000000004038d4 in ~Reader (this=0x7fffbfe60eb0) at /private/joaho/Parser/opm-parser/external/json/json-cpp/include/json/reader.h:23
#4 0x0000000000402990 in parseJson () at /private/joaho/Parser/opm-parser/opm/parser/eclipse/ExternalTests/ExternalTests.cpp:51
#5 0x00000000004029ab in main (argc=1, argv=0x7fffbfe610c8)
at /home/user/Parser/opm-parser/opm/parser/eclipse/ExternalTests/ExternalTests.cpp:56
I.e. to me it seems to crash in the destructor. As far as I can tell the Json::Reader does not have it's own dstructor, so this must be a default destructor. As you can see I am running a quite old version of g++ - could that be the problem?
As I commented:
When compiled with GCC version 4.8.1 on Debian/Sid (so libjsoncpp-dev 0.6.0~rc2-3) as g++-4.8 -g -Wall -I/usr/include/jsoncpp/ esjson.cc -ljsoncpp -o esjson your program is compiled without warnings, and does not crash when running.
And GCC 4.1.2 is really old (febr. 2007 !) and is not supported anymore, and not very well C++ standard conforming (GCC, now at version 4.8.1, has made huge progress on C++ standard conformance since 4.1).
So I am not sure GCC 4.1. is faulty, but I won't be surprised it is: it had bad C++ reputation, and both the C++ standard and the GCC compiler have been improved a lot since that. Upgrading your GCC is worth the effort, both for better support of C++ and for improved diagnostics and optimizations.
So I suggest you to use a newer GCC; if you don't have root access, consider compiling its from its source tarball; build it outside of the source tree with e.g. ../gcc-4.8.1/configure --program-suffix=-4.8 --prefix=$HOME/pub then make then make install - after having installed its dependencies
Related
I'm trying to make a multi-threaded program but am having a weird problem with thread local vectors. Here's the (stripped-down to only have the error) code:
#include <vector>
#include <iostream>
thread_local std::vector<int> vec;
int main(){
vec.push_back(3);
std::cout << vec[0];
// Make you push enter to show the error is at the end
std::cin.ignore();
}
The program compiles fine and runs mostly fine, but after I press enter I get a "program has stopped working" message. I ran it in gdb and got this error:
Program received signal SIGSEGV, Segmentation fault.
0x004030b0 in std::vector<int, std::allocator<int> >::~vector() ()
Somehow, there's an error in the vector's destructor. Going through it with a breakpoint shows that this error happens as the program is quitting.
Making the vector not thread local makes the program work, but of course I need it to be thread local. If I don't interact with the vector at all, the program works fine.
I'm thinking I'll have to use some alternative, but does anybody know a way to make this work? Thanks!
EDIT: I'm stupid and forgot more info on my system. I'm using Windows Vista 64-bit. Running g++ -v gives me:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=C:/MinGW/bin/../libexec/gcc/i686-w64-mingw32/5.2.0/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with [edited out because it's too big and probably not relevant]
Thread model: posix
gcc version 5.2.0 (i686-posix-dwarf-rev0, Built by MinGW-W64 project)
The thread model might actually have a lot to do with it.
It is setup dependent; I have successfully compiled and run your example program on Windows 7 (64 bit) with the 64 bit MinGW. Perhaps it is related to the fact that you use the 32 bit MinGW installation on 64 bit platform? My g++ -v gives the following (same version and thread model as yours, different arch):
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-w64-mingw32
Thread model: posix
gcc version 5.2.0 (x86_64-posix-seh-rev0, Built by MinGW-W64 project)
I'm compiling the Crypto++ library at -O3. According to Undefined Behavior Sanitizer (UBsan) and Address Sanitizer (Asan), its OK. The program runs fine at -O2 (and -O3 on many platforms).
Its also OK according to Valgrind under -O2. At -O3, Valgrind dies with "Your program just tried to execute an instruction that Valgrind does not understand". I'm fairly certain that's because of SSE4 instructions and vectorizations at -O3.
However, I'm catching a crash on some platforms with -O3. This particular machine is Fedora 22 i686, and its has GCC 5.2.1. The frame in question shows this=0xfffffffc:
Program received signal SIGSEGV, Segmentation fault.
0x0807be29 in CryptoPP::DL_GroupParameters_IntegerBased::GetEncodedElementSize
(this=0xfffffffc, reversible=0x1) at gfpcrypt.h:55
55 unsigned int GetEncodedElementSize(bool reversible) const {return GetModulus().ByteCount();}
The best I can tell, there's nothing located around that address:
(gdb) info shared
From To Syms Read Shared Object Library
0xb7fdd860 0xb7ff6b30 Yes (*) /lib/ld-linux.so.2
0xb7eb63d0 0xb7f7a344 Yes (*) /lib/libstdc++.so.6
0xb7e005f0 0xb7e32bd8 Yes (*) /lib/libm.so.6
0xb7951060 0xb7980cc4 Yes (*) /lib/libubsan.so.0
0xb7932090 0xb7948001 Yes (*) /lib/libgcc_s.so.1
0xb7916840 0xb79238d1 Yes (*) /lib/libpthread.so.0
0xb775d3f0 0xb78a0b6b Yes (*) /lib/libc.so.6
0xb7741a90 0xb7742a31 Yes (*) /lib/libdl.so.2
I've seen this=0x00000000 if a static class object declared in one translation unit is used in another translation unit before initialization is complete. But I don't recall seeing 0xfffffffc in the past.
What are some potential reasons for this=0xfffffffc? Or how can I troubleshoot it further?
If you have a 32 bits machine 0xfffffffc is ((int*)nullptr)-1. So perhaps you are taking the previous element of a nil pointer (e.g. wrongly using some reverse iterator, etc etc...)
Use the bt or backtrace command of gdb to understand what has happened. I guess that the trouble is in the caller (or its caller, etc...)
Try also some other compiler (e.g. some older version of GCC and several versions of Clang/LLVM....). You could have some undefined behavior that your other tools did not detect as such. You need to understand if the bug is inside Crypto++ (or perhaps, but very unlikely, it is inside GCC itself; then report a bug on GCC bugzilla....). If you suspect the compiler, pass -S -fverbose-asm -fdump-tree-all -O3 to g++ to understand what GCC is doing.... (this will dump hundreds of files, including the generated .s assembler code).
Ask also on crypto++ lists; perhaps report the bug on Crypto++ bug tracker. Test with other versions or snapshot of that library
BTW, I'm not sure that -fsanitize=undefined or -fsanitize=address should be used with -O3; I guess that they are more suitable with -O0 -g or -Og -g
--EDIT
If you would like to use MinGW GCC 8.4.1 and threads/mutex/futures/atomics do not download the Win32 threader version insted download the Posix version.
--EDIT
My installation of MinGW is as follows:
x32-4.8.1-release-win32 (as the threader) - sjlj rev 5
I have unpacked and correctly confirmed that MinGW GCC 4.8.1 (revision 5) is installed in C:\MinGW\mingw32. I have set up Code Blocks to look for the latest and greatest compiler in the correct path (this I am sure of). I can compile a normal program using #include iostream. Ok now when I try and run a program using #include thread it gives me "error: 'thread' is not a member of 'std'".
Now here is what I have done and what I have tried:
I am following a sort of template or tutorial here at cplusplus.com.
I have the code exactly as it is presented on the webpage (towards the bottom).
I have tried, in Code Blocks, to use Compiler flags "Have g++ follow the C++11 ISO language standard -std=c++11".
I have also tried the flag "Have g++ follow the coming C++0x ISO language standard -std=c++0x"
I have tried both at the same time and one at a time, no mas.
I have also tried those commands manually.
Another command I tried manually was -std=gnu++11 which was recommended in the thread header.
--EDIT
It seems like __cplusplus is < 201103L which is stated (or rather defined) in the thread header.
This only happens when I manually use -std=c++11, for some reason C::B removes it if it was manually stated so I must use a check box to use this flag...
--EDIT
My compiler settings under the Toolchain Executables tab are as follows:
C compiler: i686-w64-mingw32-gcc-4.8.1.exe
C++ compiler: i686-w64-mingw32-c++.exe
Linker for dynamic: i686-w64-mingw32-c++.exe
Linker for static: ar.exe
Debbuger: GDB/CDB debugger: default
Resource compiler: windres.exe
Make Program: mingw32-make.exe
I have tried using other executables in the bin folder and still no luck...
I'm starting to wonder if GCC supports C++11 or threading !?
Has anyone been able to get threads to work with MinGW GCC, Code blocks or in general?
If so how did you do it? Any links that might help? Any advice?
P.S. I know there are other ways of threading like posix or other SDK's like SFML (I have successfully tried threading with this). But I want to use GCC threading and I'm quite baffled as to why it is so hard to do seeing as all the necessary files are there...
--EDIT
I have found that when I manually compile the program outside of Code Blocks I still get the same errors, whether I use g++ c++ or i686-w64-mingw32-g++/c++
here is the command I run to build the files:
C:\MinGW\mingw32\bin>g++.exe -D__GXX_EXPERIMENTAL_CXX0X__ -o0 -g3
-Wall -c -fmes sage-length=0 -std=c++11 -Wc++11-compat -o obj\Debug\main.o "F:\C Projects\Code Blocks\thread\main.cpp"
still returns error: 'thread' is not a member of 'std'
Could this be a bad build? I will try other revisions...
--EDIT
probably to late for an answere, but here is what worked for me:
1. Get x86_64-w64-mingw32-gcc-4.8-stdthread-win64_rubenvb.7z from:
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/gcc-4.8-experimental-stdthread/
2. Setup a new compiler in codeblocks with
x86_64-w64-mingw32-gcc-4.8.1.exe
x86_64-w64-mingw32-g++.exe
x86_64-w64-mingw32-g++.exe
ar.exe
windres.exe
mingw32-make.exe
3. Set the new compiler for your project
Right click in your project -> build options
Select the new compiler
Under compiler falgs check -std=c++0x and -std=c++11
Under Other options set -std=gnu++11
4. Have fun with c++11 concurrency
Hope that works for you also, as an alternative you can just use visual studio.
I think you meant GCC 4.8.1 - the answer is yes, it supports a set of C++11 features including partial multi-threading support. Please visit http://gcc.gnu.org/releases.html to see supported set.
gcc 4.8.1 is C++11 feature complete. I cannot speak to the Windows implementation but certainly on Linux and OS X it works as advertised, including all the concurrency functionality. I just #include <thread> and call g++ -std=gnu++11 and it works. Here's a minimal piece of code that compiles just fine:
#include <iostream>
#include <thread>
#include <mutex>
std::mutex mx;
int i;
void thrfunc();
int main(void)
{
i=0;
std::thread thr1(thrfunc),thr2(thrfunc);
thr1.join();
thr2.join();
return 0;
}
void thrfunc()
{
mx.lock();
i++;
std::cout << std::this_thread::get_id() << " i: " << i << std::endl;
mx.unlock();
}
I had the same issues, I installed the lates MinGW-Builds
http://sourceforge.net/projects/mingwbuilds/files/mingw-builds-install/
and set my toolchain executables to:
x86_64-w64-mingw32-gcc-4.8.1.exe
x86_64-w64-mingw32-g++.exe
x86_64-w64-mingw32-g++.exe
ar.exe
windres.exe
mingw32-make.exe
I hope this helps.
I'm experiencing some very weird problems with static boost libraries (Boost 1.45.0-2 from MacPorts, compiled as fat/universal (x86/x86_64) libraries) under Mac OS X 10.6.6 with GCC 4.5.
The error message is
main(78485) malloc: *** error for object 0x1000e0b20: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
[1] 78485 abort (core dumped)
and a tiny bit of example code which will trigger this problem:
#define BOOST_FILESYSTEM_VERSION 3
#include <boost/filesystem.hpp>
#include <iostream>
int main (int argc, char **argv) {
std::cout << boost::filesystem::current_path ().string () << '\n';
}
This problem always occurs when linking the static boost libraries into the binary. Linking dynamically will work fine, though.
Even more information:
gcc versions tested/used: Apple GCC 4.2.1 (works/runs), MacPorts GCC 4.5.2 (fails)
flags tested/used: none, -fPIC, -fPIC -g, -fPIC -g -ggdb3 -gdwarf-2 -O0
gdb output with MP GCC 4.5.2/any flags of the above:
(gdb) run
Starting program: /Users/ionic/crashtest/bin/ctest Reading symbols for shared libraries .++++++++++++++++++++++.................................................................................................................. done
ctest(80366) malloc: *** error for object 0x100fe6b20: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Program received signal SIGABRT, Aborted. 0x00007fff81a4e616 in __kill ()
(gdb) bt full
#0 0x00007fff81a4e616 in __kill () No symbol table info available.
#1 0x00007fff81aeecca in abort () No symbol table info available.
#2 0x00007fff81a066f5 in free () No symbol table info available.
#3 0x0000000100f763e9 in std::string::_M_mutate () No symbol table info available.
#4 0x0000000100f7644c in std::string::_M_replace_safe () No symbol table info available.
#5 0x0000000100f77edd in std::string::replace () No symbol table info available.
#6 0x000000010000713d in std::string::_M_rep () at /usr/include/c++/4.2.1/bits/basic_string.h:1412
to = (string &) Cannot access memory at address 0x0
Seems like it's working fine with Apple's (quite old) GCC version, but failing badly with the new GCC build by MacPorts.
otool -L ctest:
./../../bin/ctest:
/opt/local/lib/gcc45/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.14.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 625.0.0)
/opt/local/lib/gcc45/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.1)
I've seen various reports for quite a similar OS X bug with GCC 4.2 and the _GLIBCXX_DEBUG macro set, but this one seems even more generic, as I'm neither using XCode, nor setting the macro (even undefining it does not help. I tried it just to make sure it's really not related to this problem.) Doesn't seem to be related at all to this problem, as the same code is working fine with Apple's GCC.
As Apple's GCC doesn't include any C++0x features yet, I'd indeed like to use the currently stable GCC version.
Does anybody have any pointers to why this is happening or even maybe a solution (rather than using the dynamic library workaround)?
Best regards,
Mihai
The problem was that Boost has been built using Apple's GCC 4.2.1, whilst I've been building the project using a different compiler.
As I tried to link the static Boost libraries, also the GCC 4.2.1 libstdc++ was put into the binary.
However, at the same time the other GCC version was linking in its libstdc++ and name space problems were inherent, thus the wrong functions were called and the like.
The most simple fix is re-building Boost with your target GCC version and retry the building of your program (ofc. using the self-built Boost.)
Be warned: do not try to change the compiler MacPorts uses for building Boost (it's even not easily possible), or system breakage may occur. Instead, build Boost on your own.
The following code crashes for me using GCC to build for ARM:
#include <vector>
using namespace std;
void foo(vector<bool>& bools) {
bools.push_back(true);
}
int main(int argc, char** argv) {
vector<bool> bools;
bool b = false;
bools.push_back(b);
}
My compiler is: arm_v5t_le-gcc (GCC) 3.4.3 (MontaVista 3.4.3-25.0.30.0501131 2005-07-23). The crash doesn't occur when building for debug, but occurs with optimizations set to -O2.
Yes, the foo function is necessary to reproduce the issue. This was very confusing at first, but I've discovered that the crash only happens when the push_back call isn't inlined. If GCC notices that the push_back method is called more than once, it won't inline it in each location. For example, I can also reproduce the crash by calling push_back twice inside of main. If you make foo static, then gcc can tell it is never called and will optimize it out, resulting in push_back getting inlined into main, resulting in the crash not occurring.
I've tried this on x86 with gcc 4.3.3, and it appears the issue is fixed for that version.
So, my questions are:
Has anyone else run into this? Perhaps there are some compiler flags I can pass in to prevent it.
Is this a bug with gcc's code generation, or is it a bug in the stl implementation (bits/stl_bvector.h)? (I plan on testing this out myself when I get the time)
If it is a problem with the compiler, is upgrading to 4.3.3 what fixes it, or is it switching to x86 from arm?
Incidentally, most other vector<bool> methods seem to work. And yes, I know that using vector<bool> isn't the best option in the world.
Can you build your own toolchain with gcc 3.4.6 and Montavista's patches? 3.4.6 is the last release of the 3.x line.
I can append some instructions for how to build an ARM cross-compiler from GCC sources if you want. I have to do it all the time, since nobody does prebuilt toolchains for Mac OS X.
I'd be really surprised if this is broken for ARM in gcc 4.x. But the only way to test is if you or someone else can try this out on an ARM-targeting gcc 4.x.
Upgrading to GCC 4 is a safe bet. Its code generation backend replaces the old RTL (Register Transfer Language) representation with SSA (Static Single Assignment). This change allowed a significant rewrite of the optimizer.