Hi, Thanks for the report - I'll investigate the issue and let you know. We do not use std::shared_ptr as we want to let C++03 applications use Ignite too.
Best Regards, Igor On Fri, May 12, 2017 at 11:56 AM, tolga <[email protected]> wrote: > There seems to be some kind of race situation: > 0x0000000001381206 in std::less<int>::operator() (this=0x1a4e4b0, > __x=<error > reading variable>, __y=@0x7fff80846e04: 2066246303) at > /usr/include/c++/6.3.1/bits/stl_function.h:386 > #4 0x00000000015040cd in > ignite::impl::binary::BinaryTypeManager::GetHandler (this=0x1a560d0, > typeName="test.data", typeId=2066246303) at > src/impl/binary/binary_type_manager.cpp:56 > 56 std::map<int32_t, SPSnap>::iterator it = > snapshots0.find(typeId); > (gdb) print snapshots0 > $10 = std::map with 42286576 elements = {[42312864] = {ptr = 0x285a4a0, > impl > = 0x0}<error reading variable: Cannot access memory at address 0x110>...} > (gdb) print snapshot > $11 = {ptr = 0x7fffffffda4f, impl = 0x11} > `impl` pointers seems to be corrupted on multiple places. Why aren't you > using `std::shared_ptr` instead of your own concurrent shared pointer? > > > > -- > View this message in context: http://apache-ignite-users. > 70518.x6.nabble.com/Ignite-2-0-C-Segfault-tp12652p12657.html > Sent from the Apache Ignite Users mailing list archive at Nabble.com. >
