You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ignite.apache.org by Tolga HOŞGÖR <fa...@gmail.com> on 2017/05/12 07:55:41 UTC
Ignite 2.0 C++ Segfault
The following segfault happens in multi-threaded ignite c++ application:
C [test+0xf8116a] std::less<int>::operator()(int const&, int const&)
const+0x14
C [test+0x1106305] std::_Rb_tree<int, std::pair<int const,
ignite::common::concurrent::SharedPointer<ignite::impl::binary::BinaryTypeSnapshot>
>, std::_Select1st<std::pair<int const,
ignite::common::concurrent::SharedPointer<ignite::impl::binary::BinaryTypeSnapshot>
> >, std::less<int>, std::allocator<std::pair<int const,
ignite::common::concurrent::SharedPointer<ignite::impl::binary::BinaryTypeSnapshot>
> > >::_M_lower_bound(std::_Rb_tree_node<std::pair<int const,
ignite::common::concurrent::SharedPointer<ignite::impl::binary::BinaryTypeSnapshot>
> >*, std::_Rb_tree_node_base*, int const&)+0x41
C [test+0x1105a9d] std::_Rb_tree<int, std::pair<int const,
ignite::common::concurrent::SharedPointer<ignite::impl::binary::BinaryTypeSnapshot>
>, std::_Select1st<std::pair<int const,
ignite::common::concurrent::SharedPointer<ignite::impl::binary::BinaryTypeSnapshot>
> >, std::less<int>, std::allocator<std::pair<int const,
ignite::common::concurrent::SharedPointer<ignite::impl::binary::BinaryTypeSnapshot>
> > >::find(int const&)+0x45
C [test+0x1104e7f] std::map<int,
ignite::common::concurrent::SharedPointer<ignite::impl::binary::BinaryTypeSnapshot>,
std::less<int>, std::allocator<std::pair<int const,
ignite::common::concurrent::SharedPointer<ignite::impl::binary::BinaryTypeSnapshot>
> > >::find(int const&)+0x23
C [test+0x1104031]
ignite::impl::binary::BinaryTypeManager::GetHandler(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&, int)+0x6f
C [test+0xe6de2d] void
ignite::impl::binary::BinaryWriterImpl::WriteTopObject<std::shared_ptr<test::data>
>(std::shared_ptr<test::data> const&)+0xbb
C [test+0xe6cd48]
ignite::impl::In2Operation<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >, std::shared_ptr<test::data>
>::ProcessInput(ignite::impl::binary::BinaryWriterImpl&)+0x3e
C [test+0x1128cf1]
ignite::impl::interop::InteropTarget::WriteTo(ignite::impl::interop::InteropMemory*,
ignite::impl::InputOperation&, ignite::IgniteError&)+0xa9
C [test+0x1128f67] ignite::impl::interop::InteropTarget::OutOp(int,
ignite::impl::InputOperation&, ignite::IgniteError&)+0x65
C [test+0x1125f41]
ignite::impl::cache::CacheImpl::Put(ignite::impl::InputOperation&,
ignite::IgniteError&)+0x2d
C [test+0xe5539a] ignite::cache::Cache<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >, std::shared_ptr<test::data>
>::Put(std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > const&, std::shared_ptr<test::data> const&,
ignite::IgniteError&)+0x52
Re: Ignite 2.0 C++ Segfault
Posted by Igor Sapego <is...@gridgain.com>.
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 <fa...@gmail.com> 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.
>
Re: Ignite 2.0 C++ Segfault
Posted by tolga <fa...@gmail.com>.
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.