Author Topic: segfault in 0.4.19  (Read 17920 times)

0 Members and 1 Guest are viewing this topic.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
if run the client with

 --server --accept-incoming-connections 0 --max-connections 10

however .. I eventually lose ALL connections .. :(

Offline spartako

  • Sr. Member
  • ****
  • Posts: 401
    • View Profile
Just crashed in my "seed" node that accept incoming connections:

Code: [Select]
(wallet closed) >>>
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffb3fff700 (LWP 41682)]
0x0000000000a55777 in std::_Hashtable<bts::net::item_id, bts::net::item_id, std::allocator<bts::net::item_id>, std::__detail::_Identity, std::equal_to<bts::net::item_id>, std::hash<bts::net::item_id>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<true, true, true> >::_M_find_before_node(unsigned long, bts::net::item_id const&, unsigned long) const () at /usr/include/c++/4.8/bits/hashtable.h:1159
1159          __node_base* __prev_p = _M_buckets[__n];
(gdb) bt
#0  0x0000000000a55777 in std::_Hashtable<bts::net::item_id, bts::net::item_id, std::allocator<bts::net::item_id>, std::__detail::_Identity, std::equal_to<bts::net::item_id>, std::hash<bts::net::item_id>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<true, true, true> >::_M_find_before_node(unsigned long, bts::net::item_id const&, unsigned long) const () at /usr/include/c++/4.8/bits/hashtable.h:1159
#1  0x0000000000a55840 in std::_Hashtable<bts::net::item_id, bts::net::item_id, std::allocator<bts::net::item_id>, std::__detail::_Identity, std::equal_to<bts::net::item_id>, std::hash<bts::net::item_id>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<true, true, true> >::find(bts::net::item_id const&) ()
    at /usr/include/c++/4.8/bits/hashtable.h:604
#2  0x0000000000a3dbc3 in bts::net::detail::node_impl::process_block_during_normal_operation(bts::net::peer_connection*, bts::client::block_message const&, fc::ripemd160 const&) ()
    at /usr/include/c++/4.8/bits/unordered_set.h:517
#3  0x0000000000a3f48b in bts::net::detail::node_impl::process_block_message(bts::net::peer_connection*, bts::net::message const&, fc::ripemd160 const&) ()
    at /home/fabiux/ssd/bitsharesx/libraries/net/node.cpp:2880
#4  0x0000000000a40bd3 in bts::net::detail::node_impl::on_message(bts::net::peer_connection*, bts::net::message const&) () at /home/fabiux/ssd/bitsharesx/libraries/net/node.cpp:1598
#5  0x0000000000aaef3a in bts::net::detail::message_oriented_connection_impl::read_loop() () at /home/fabiux/ssd/bitsharesx/libraries/net/message_oriented_connection.cpp:157
#6  0x0000000000ab130c in fc::detail::void_functor_run<bts::net::detail::message_oriented_connection_impl::accept()::{lambda()#1}>::run(void*, fc::detail::void_functor_run<bts::net::detail::message_oriented_connection_impl::accept()::{lambda()#1}>) () at /home/fabiux/ssd/bitsharesx/libraries/net/message_oriented_connection.cpp:100
#7  0x00000000006adc53 in fc::task_base::run_impl() () at /home/fabiux/ssd/bitsharesx/libraries/fc/src/thread/task.cpp:43
#8  0x00000000006ac47b in fc::thread_d::process_tasks() () at /home/fabiux/ssd/bitsharesx/libraries/fc/src/thread/thread_d.hpp:415
#9  0x00000000006ac716 in fc::thread_d::start_process_tasks(long) () at /home/fabiux/ssd/bitsharesx/libraries/fc/src/thread/thread_d.hpp:395
#10 0x0000000000f1f9ce in make_fcontext ()
#11 0x00007fffa80008c0 in ?? ()
#12 0x00007fff8d02a530 in ?? ()
#13 0x0000000000000000 in ?? ()
(gdb)

My delegate node (without incoming connection and limit to 20 connection) is OK until now.
wallet_account_set_approval spartako

Offline GaltReport

I suggest monitor memory frequently.  I have a delegate that got low on memory just running overnight so I rebooted it.  Haven't crashed or missed blocks yet but I would for sure keep a close eye on it.

Edit: Linux command to check memory: free

« Last Edit: October 02, 2014, 11:47:06 am by GaltReport »

Offline xfund

  • Full Member
  • ***
  • Posts: 148
    • View Profile
    • FUND投票基金
  • BitShares: xfund
Thanks very much +5%
Asset:FUND

Offline svk

I've reduced my number of max connections to 10, running OK so far but monitoring it..

How to do?

network_set_advanced_node_parameters {"maximum_number_of_connections":10}
Worker: dev.bitsharesblocks

Offline spartako

  • Sr. Member
  • ****
  • Posts: 401
    • View Profile
I'm running with  --accept-incoming-connections 0 flag and
> network_set_advanced_node_parameters {"desired_number_of_connections":20, "maximum_number_of_connections":20}

No crash of 0.4.19 until now after 1 hour...monitoring
wallet_account_set_approval spartako

Offline xfund

  • Full Member
  • ***
  • Posts: 148
    • View Profile
    • FUND投票基金
  • BitShares: xfund
I've reduced my number of max connections to 10, running OK so far but monitoring it..

How to do?
Asset:FUND

Offline svk

I've reduced my number of max connections to 10, running OK so far but monitoring it..
Worker: dev.bitsharesblocks

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Btw .. it seems init delegates also crashed ..

Offline serejandmyself

  • Sr. Member
  • ****
  • Posts: 358
    • View Profile
mine is crashing out all the time also
btsx - bitsharesrussia

Offline liondani

  • Hero Member
  • *****
  • Posts: 3737
  • Inch by inch, play by play
    • View Profile
    • My detailed info
  • BitShares: liondani
  • GitHub: liondani

Offline bitcoinerS

  • Hero Member
  • *****
  • Posts: 592
    • View Profile
0.4.19 is not safe to run. It keeps crashing.  I am switching back to 0.4.18
>>> approve bitcoiners

Offline svk

Same here, three segfaults so far, one on the delegate machine, two on the bitsharesblocks machine..
Worker: dev.bitsharesblocks

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Should we panic?
na ..

delegates can still run version 0.4.18 ....
actually if the delegates were to choose not to update to 0.4.19 (which they shouldn't do currently) there will not be the hardfork at 640000:)

Offline lakerta06

Should we panic?