I've recently updated my Gentoo Linux PC with GCC 5.4.0.
I also recompiled all packages depending on gcc (it was mentioned in gcc upgrade guide for gentoo).
Most of programs works well, however my tests, using cppunit, throw std::bad_alloc before starting.
At first I thought there might be a problem with updated version of cppunit, so I downgraded it to previous version, but the problem still exists.
Whenever I start any test, the application immediately throws:
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
I started the application in gdb and printed debug backtrace:
#0 0x00007ffff545d218 in raise () from /lib64/libc.so.6
#1 0x00007ffff545e69a in abort () from /lib64/libc.so.6
#2 0x00007ffff5d8f18d in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libstdc++.so.6
#3 0x00007ffff5d8d046 in ?? () from /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libstdc++.so.6
#4 0x00007ffff5d8d091 in std::terminate() () from /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libstdc++.so.6
#5 0x00007ffff5d8d297 in __cxa_throw () from /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libstdc++.so.6
#6 0x00007ffff5db5f52 in std::__throw_bad_alloc() () from /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libstdc++.so.6
#7 0x0000000000b2b3ae in __gnu_cxx::new_allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >::allocate
(this=0x7fffffffda58, __n=18446741874689290911) at /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/include/g++-v5/ext/new_allocator.h:102
#8 0x0000000000b2b1e2 in std::allocator_traits<std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >::allocate (__a=..., __n=18446741874689290911) at /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/include/g++-v5/bits/alloc_traits.h:491
#9 0x0000000000b2b09e in std::__cxx1998::_Vector_base<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >::_M_allocate (this=0x7fffffffda58,
__n=18446741874689290911) at /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/include/g++-v5/bits/stl_vector.h:170
#10 0x0000000000b2af71 in std::__cxx1998::_Vector_base<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >::_M_create_storage (this=0x7fffffffda58,
__n=18446741874689290911) at /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/include/g++-v5/bits/stl_vector.h:185
#11 0x0000000000b2acf1 in std::__cxx1998::_Vector_base<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >::_Vector_base (this=0x7fffffffda58,
__n=18446741874689290911, __a=...) at /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/include/g++-v5/bits/stl_vector.h:136
#12 0x0000000000b29c9c in std::__cxx1998::vector<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >::vector (this=0x7fffffffda58,
__x=std::__cxx1998::vector of length -2199020260704, capacity -2199020259433 = {...}) at /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/include/g++-v5/bits/stl_vector.h:320
#13 0x0000000000b29449 in std::__debug::vector<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >::vector (this=0x7fffffffda40)
at /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/include/g++-v5/debug/vector:193
#14 0x0000000000b294ef in CppUnit::TestSuiteBuilderContextBase::TestSuiteBuilderContextBase (this=0x7fffffffda20) at /usr/include/cppunit/extensions/TestSuiteBuilderContext.h:29
#15 0x0000000000b29515 in CppUnit::TestSuiteBuilderContext<Types_Decimal>::TestSuiteBuilderContext (this=0x7fffffffda20, contextBase=...) at /usr/include/cppunit/extensions/TestSuiteBuilderContext.h:106
#16 0x0000000000b28a16 in Types_Decimal::addTestsToSuite (baseContext=...) at ./Tests/../../pCpp/CppUnitTests/Types_Decimal.hpp:10
#17 0x0000000000b28caa in Types_Decimal::suite () at ./Tests/../../pCpp/CppUnitTests/Types_Decimal.hpp:12
#18 0x0000000000b2871f in main () at Types_Decimal.cpp:8
There is no problem with test file itself, because I made no changes to it, and lots of test were working for long time.
After looking into stack trace, I'm pretty curious what happened on frame #12: __x=std::**__cxx1998**::vector of length **-2199020260704**, capacity **-2199020259433** = {...}
Why there is cxx1998? Both length and capacity looks pretty insane (uninitialized?).
TestSuiteBuilderContext.h:29:
void
TestSuiteBuilderContextBase::addTest( Test *test )
{
m_suite.addTest( test ); //line 29
}
TestSuite.cpp:
/// Adds a test to the suite.
void
TestSuite::addTest( Test *test )
{
m_tests.push_back( test );
}
I came up with partial solution.
It looks like the compile option:
-D_GLIBCXX_DEBUG
Was causing the problem. After removing it - tests run succesfully.
Related
I recently updated to fedora 30. When running a test now, my code will coredump on the CPPUNIT_ASSERT in the destrctor of the Message,
gcc version:
gcc (GCC) 9.3.1 20200408 (Red Hat 9.3.1-2)
Copyright (C) 2019 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.
Cppunit version:
Installed Packages
cppunit.x86_64 1.14.0-7.fc30 #fedora
backtrace:
#0 0x00007ff037a363ff in free () from /lib64/libjemalloc.so.2
#1 0x000000000044ea37 in __gnu_cxx::new_allocator<char>::deallocate (this=0x7ff02fefc000, __p=0x1 <error: Cannot access memory at address 0x1>)
at /usr/include/c++/9/ext/new_allocator.h:128
#2 0x000000000044cc39 in std::allocator_traits<std::allocator<char> >::deallocate (__a=..., __p=0x1 <error: Cannot access memory at address 0x1>
, __n=70999306) at /usr/include/c++/9/bits/alloc_traits.h:470
#3 0x000000000043eb9f in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_destroy (this=0x7ff02fefc000, __siz
e=70999305) at /usr/include/c++/9/bits/basic_string.h:237
#4 0x000000000043df95 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_dispose (this=0x7ff02fefc000) at /u
sr/include/c++/9/bits/basic_string.h:232
#5 0x000000000043b9a5 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string (this=0x7ff02fefc000, __
in_chrg=<optimized out>) at /usr/include/c++/9/bits/basic_string.h:658
#6 0x0000000000738397 in std::_Destroy<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > (__pointer=0x7ff02fefc0
00) at /usr/include/c++/9/bits/stl_construct.h:98
#7 0x00000000007359f9 in std::_Destroy_aux<false>::__destroy<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*> (
__first=0x7ff02fefc000, __last=0x7ff02fefb460) at /usr/include/c++/9/bits/stl_construct.h:108
#8 0x00000000007326a2 in std::_Destroy<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*> (__first=0x7ff02fefb5e0
, __last=0x7ff02fefb460) at /usr/include/c++/9/bits/stl_construct.h:137
#9 0x000000000072fb65 in std::_Destroy<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, std::__cxx11::basic_str
ing<char, std::char_traits<char>, std::allocator<char> > > (__first=0x7ff02fefb5e0, __last=0x7ff02fefb460) at /usr/include/c++/9/bits/stl_constru
ct.h:206
#10 0x000000000075d72d in std::deque<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11
::basic_string<char, std::char_traits<char>, std::allocator<char> > > >::_M_destroy_data_aux (this=0x7fffdd38c658, __first="", __last=non-derefer
enceable iterator for std::deque) at /usr/include/c++/9/bits/deque.tcc:864
#11 0x00007ff0384e52ed in CppUnit::Message::~Message() () from /lib64/libcppunit-1.14.so.0
#12 0x0000000000ed4ac8 in UT_MyTest::basic(this=0x7ff034b294b0, chunks=std::vector of lengt
h 1000, capacity 1024 = {...}, index=...) at /home/felix/git/master/src/core/UT_MyTest.cpp:708
Removing the CPPUNIT_ASSERT on line 708 enables the test to pass without issue - including it coredumps with this dump above. The values of __first and __last are "" - not sure if that will cause it to dump. I'm thinking my versioning is off, but I'm not sure. Has anyone any suggestions?
Edit:
The line it coredumps on for this particular test:
CPPUNIT_ASSERT(correctHashes != 0);
This coredump happens in any test that use CPPUNIT_ASSERT
Upgrading to cppunit 1.15 from the fc32 repo fixed the issue for me.
So everything was working great until I decided to comment out a print method (for debugging). Once I commented it out, my code began to seg fault.
I assumed this was because I was somehow modifying something in my print method, so I commented out one line at a time so I could find where it was happening. After commenting every single line in the print out, I noticed it would seg fault only when I wasn't calling the print method (even if it was completely empty!).
So I did this:
void emptyMethod(Qclass c) {}
void Typechecker::initializeClasses(AST::Node *astRoot) {
...
Qclass clazz;
...
this->classes[clazz.name] = clazz;
emptyMethod(clazz); // I have no idea why I have to do this, but it
seg faults if I don't
...
}
This fixes my seg fault.
Structs in question:
struct Qclass; // forward declare
struct Qmethod {
AST::Node *node; // pointer to the node in the tree
// The reference to the containing class of a method is a pointer because
// it may not be fully initialized when passed into any given Qmethod.
// This is okay because we don't use *clazz until after all initialization is
complete.
Qclass *clazz;
std::string name;
std::vector<std::string> init;
std::map<std::string, std::string> type;
std::vector<AST::Node*> stmts;
};
struct Qclass {
AST::Node *node; // pointer to the node in the tree
std::string name;
std::string super;
Qmethod constructor;
std::vector<Qmethod> methods;
// for use in init before use checking in non constructor methods
std::vector<std::string> instanceVars;
};
Where it is seg faulting:
bool Typechecker::initCheckStmt(Qmethod &method, AST::Node *stmt, bool isConstructor) {
...
method.clazz->instanceVars.push_back(left->get(IDENT)->name); // seg faults here when not calling the empty method
...
return true;
}
Seg fault error:
#0 0x00007fffff1919b8 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
#1 0x000000000041ab38 in void __gnu_cxx::new_allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::construct<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&>(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) ()
#2 0x0000000000417dc6 in void std::allocator_traits<std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >::construct<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&>(std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) ()
#3 0x0000000000415b56 in std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >::push_back(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) ()
#4 0x00000000004136b3 in Typechecker::initCheckStmt(Qmethod&, AST::Node*, bool) ()
#5 0x00000000004134b9 in Typechecker::getLeaves(Qmethod&, AST::Node*, std::vector<AST::Node*, std::allocator<AST::Node*> >&, bool) ()
#6 0x00000000004137c8 in Typechecker::initCheckQmethod(Qmethod&, bool) ()
#7 0x0000000000413a16 in Typechecker::initializeBeforeUseCheck() ()
#8 0x0000000000413d12 in Typechecker::checkProgram() ()
#9 0x0000000000426e7b in main ()
I can see it must have something to do with the instanceVars vector, but I don't understand why an empty method call would fix it. My Googling ability isn't helping me at all, so any pointers would be very much appreciated.
(this code is for a compilers course)
You've got yourself some undefined behavior. Your program is doing something—maybe an out-of-bounds memory access, who knows—that is throwing off your program. In C++, when your program does that, all bets are off for what it does next, including segfaulting.
That empty method call is hiding the bug, but it's not fixing the bug. As you correctly noted, that method call shouldn't affect whether it segfaults. The reason why it does is because of the undefined behavior.
To solvev this, you'll need to look at the rest of your program to determine where there might be an issue. Just the one line where it broke isn't enough; you should look before and after the line where it ends up segfaulting, as well as what you're passing into initializeClasses.
I'm trying to do this:
int main(){
std::unique_ptr<std::thread> up(nullptr);
up = std::make_unique<std::thread>(upload, url, path);
return 0;
}
where, upload is basically a static non-member function and url and path are std::string. upload is defined as:
static void upload(const string url, const string path){ int sync_status;}
But this is always getting reported as a memory leak under Valgrind:
249 (80 direct, 169 indirect) bytes in 1 blocks are definitely lost in loss record 151 of 169
==12088== at 0x4C3017F: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12088== by 0x1395F9: _S_make_state<std::thread::_Invoker<std::tuple<void (*)(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >), std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> , std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > (thread:197)
==12088== by 0x1395F9: thread<void (&)(std::__cxx11::basic_string<char>, std::__cxx11::basic_string<char>), std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> &> (thread:126)
==12088== by 0x1395F9: std::_MakeUniq<std::thread>::__single_object std::make_unique<std::thread, void (&)(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> ), std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&>(void (&)(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >), std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> &, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&) (unique_ptr.h:825)
==12088== by 0x131D8D: main
Your code ends up invoking std::thread::~thread which calls std::terminate because the thread is neither detached nor joined. This is why valgrind reports an error.
Either join or detach the thread.
My app is using boost::program_options and it's triggering an AddressSanitizer "stack-buffer-overflow" while generating an error message from an exception.
I'm not worried about the boost bug - the functionality works and this is just in the command line parsing portion of a non-production app. However I'd like to suppress the AddressSanitizer message.
ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffe6ce7070 at pc 0x0000007406cd bp 0x7fffe6ce6fe0 sp 0x7fffe6ce6fd8
READ of size 8 at 0x7fffe6ce7070 thread T0
#0 0x7406cc in std::_Head_base<0ul, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&&, false>::_M_head(std::_Head_base<0ul, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&&, false>&) /frc/toolchain6/include/c++/5.3.0/tuple:142
#1 0x7406cc in _M_create_node /frc/toolchain6/include/c++/5.3.0/tuple:347
#2 0x7403fd in std::_Rb_tree_iterator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >::_M_emplace_hint_unique<std::piecewise_construct_t const&, std::tuple<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&&>, std::tuple<> >(std::_Rb_tree_const_iterator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::piecewise_construct_t const&, std::tuple<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&&>&&, std::tuple<>&&) /frc/toolchain6/include/c++/5.3.0/bits/stl_tree.h:2170
#3 0xd5eff8 in boost::program_options::error_with_option_name::substitute_placeholders(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const (/home/joe/myapp_workspace/myapp/myapp-debug+0xd5eff8)
#4 0xd5c0dd in boost::program_options::error_with_option_name::what() const (/home/joe/myapp_workspace/myapp/myapp-debug+0xd5c0dd)
#5 0x58addf in main /home/joe/myapp_workspace/myapp/main.cpp:62
#6 0x7fd7e056176c in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2176c)
#7 0x436aa0 (/home/joe/myapp_workspace/myapp/myapp-debug+0x436aa0)
I've tried using the ASAN_OPTIONS suppression file method but that only seems to support a very short list of error types (such as "vptr_check" and "leak").
I don't think there's an easy way to suppress this error - Clang version of Asan has blacklisting mechanism but it's context insensitive so you'd have to disable memory checking in all usages of std::string which is highly undesirable.
One option is to use -fsanitize-recover=address compiler flag and add halt_on_error=0 to your ASAN_OPTIONS environment variable (see wiki for details and note that recovery is only supported is relatively new GCC and Clang). This will continue execution after first error. You'll then be able to examine full Asan report and select what interests you.
We are using read_json() in different processes and we are getting below crashes.
#0 0x00007f062ce0d094 in std::mem_fun1_t<int, boost::spirit::classic::impl::grammar_helper_base<boost::spirit::classic::grammar<boost::property_tree::json_parser::json_grammar<boost::property_tree::basic_ptree<std::string, std::string, std::less<std::string> > >, boost::spirit::classic::parser_context<boost::spirit::classic::nil_t> > >, boost::spirit::classic::grammar<boost::property_tree::json_parser::json_grammar<boost::property_tree::basic_ptree<std::string, std::string, std::less<std::string> > >, boost::spirit::classic::parser_context<boost::spirit::classic::nil_t> >*>::operator() (this=0x7f06120f4c90, __p=0x7f05f813faa0, __x=0x7f06120f4df0) at /usr/lib/gcc/x86_64-spcdn-linux-gnu/4.5.2/../../../../include/c++/4.5.2/bits/stl_function.h:605
#1 0x00007f062ce0c66e in std::binder2nd<std::mem_fun1_t<int, boost::spirit::classic::impl::grammar_helper_base<boost::spirit::classic::grammar<boost::property_tree::json_parser::json_grammar<boost::property_tree::basic_ptree<std::string, std::string, std::less<std::string> > >, boost::spirit::classic::parser_context<boost::spirit::classic::nil_t> > >, boost::spirit::classic::grammar<boost::property_tree::json_parser::json_grammar<boost::property_tree::basic_ptree<std::string, std::string, std::less<std::string> > >, boost::spirit::classic::parser_context<boost::spirit::classic::nil_t> >*> >::operator() (this=0x7f06120f4c90, __x=#0x7f06001446e0) at /usr/lib/gcc/x86_64-spcdn-linux-gnu/4.5.2/../../../../include/c++/4.5.2/backward/binders.h:154
#2 0x00007f062ce0b87e in std::for_each<std::reverse_iterator<__gnu_cxx::__normal_iterator<boost::spirit::classic::impl::grammar_helper_base<boost::spirit::classic::grammar<boost::property_tree::json_parser::json_grammar<boost::property_tree::basic_ptree<std::string, std::string, std::less<std::string> > >, boost::spirit::classic::parser_context<boost::spirit::classic::nil_t> > >**, std::vector<boost::spirit::classic::impl::grammar_helper_base<boost::spirit::classic::grammar<boost::property_tree::json_parser::json_grammar<boost::property_tree::basic_ptree<std::string, std::string, std::less<std::string> > >, boost::spirit::classic::parser_context<boost::spirit::classic::nil_t> > >*, std::allocator<boost::spirit::classic::impl::grammar_helper_base<boost::spirit::classic::grammar<boost::property_tree::json_parser::json_grammar<boost::property_tree::basic_ptree<std::string, std::string, std::less<std::string> > >, boost::spirit::classic::parser_context<boost::spirit::classic::nil_t> > >*> > > >, std::binder2nd<std::mem_fun1_t<int, boost::spirit::classic::impl::grammar_helper_base<boost::spirit::classic::grammar<boost::property_tree::json_parser::json_grammar<boost::property_tree::basic_ptree<std::string, std::string, std::less<std::string> > >, boost::spirit::classic::parser_context<boost::spirit::classic::nil_t> > >, boost::spirit::classic::grammar<boost::property_tree::json_parser::json_grammar<boost::property_tree::basic_ptree<std::string, std::string, std::less<std::string> > >, boost::spirit::classic::parser_context<boost::spirit::classic::nil_t> >*> > > (__first=..., __last=..., __f=...) at /usr/lib/gcc/x86_64-spcdn-linux-gnu/4.5.2/../../../../include/c++/4.5.2/bits/stl_algo.h:4185
#3 0x00007f062ce0aa88 in boost::spirit::classic::impl::grammar_destruct<boost::spirit::classic::grammar<boost::property_tree::json_parser::json_grammar<boost::property_tree::basic_ptree<std::string, std::string, std::less<std::string> > >, boost::spirit::classic::parser_context<boost::spirit::classic::nil_t> > > (self=0x7f06120f4df0) at /usr/include/boost/spirit/home/classic/core/non_terminal/impl/grammar.ipp:324
#4 0x00007f062ce09c5f in boost::spirit::classic::grammar<boost::property_tree::json_parser::json_grammar<boost::property_tree::basic_ptree<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, boost::spirit::classic::parser_context<boost::spirit::classic::nil_t> >::~grammar (this=0x7f06120f4df0, __in_chrg=<optimized out>) at /usr/include/boost/spirit/home/classic/core/non_terminal/grammar.hpp:52
#5 0x00007f062ce093f7 in boost::property_tree::json_parser::json_grammar<boost::property_tree::basic_ptree<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >::~json_grammar (this=0x7f06120f4df0, __in_chrg=<optimized out>) at /usr/include/boost/property_tree/detail/json_parser_read.hpp:162
#6 0x00007f062ce0987f in boost::property_tree::json_parser::read_json_internal<boost::property_tree::basic_ptree<std::string, std::string, std::less<std::string> > > (stream=..., pt=..., filename="") at /usr/include/boost/property_tree/detail/json_parser_read.hpp:310
#7 0x00007f062ce08eb6 in boost::property_tree::json_parser::read_json<boost::property_tree::basic_ptree<std::string, std::string, std::less<std::string> > > (stream=..., pt=...) at /usr/include/boost/property_tree/json_parser.hpp:45
But when I define BOOST_SPIRIT_THREADSAFE at every place where I used this function, every thing is working fine. But I didn't understand this because every process will be having different address space. So even Sprit annoyingly makes a static variable in grammar.ipp that'll be shared amongst all instances of Spirit, how it will be shared across different processes?
So even Sprit annoyingly makes a static variable in grammar.ipp that'll be shared amongst all instances of Spirit, how it will be shared across different processes?
It isn't. Period.
Your program might share some files/named kernel objects on it's own, but the library doesn't.
This gives me worries though:
But when I define BOOST_SPIRIT_THREADSAFE at every place where I used this function
You should define it globally. That is before inclusion of ANY boost header in ALL translation units.
Failure to do so at least fails to guarantee that all global state is guarded (think of locale character classification and properties) and might easily violate the One-Definition-Rule