Bus Error

snap
1

Hello.
I built my first snap.
Testing for SNAP, I discovered some problems:

  1. Slow network. A program built from source codes synchronizes blocks faster than snap packages.
  2. The work of the snap package ends in an error - Bus Error.
https://i.postimg.cc/5y5XNKBH/Screenshot-20190121-171753.png
2

Is the snap version using same library versions as the non-snap one?

Is the non snap version using hardware acceleration to calculate hashes?

You should use a debugger to find out what’s causing this.

3

Hello! Thank you for responding.

I assume that yes, I do not know how to check it.

Absolutely not

Is there any specificity for snap?

4

Which snap is this?

You need to start gdb through a wrapper that is included in snapd package. Execute snap run --gdb <snap>.<app>. Then it’s just the regular gdb. Grab a backtrace when bus error pops up.

5 
Thread 6 "vizd" received signal SIGBUS, Bus error.
[Switching to LWP 19945]
0x0000000000c2b114 in boost::multi_index::detail::ordered_index_node_impl<boost::interprocess::allocator<char, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index> > >::rebalance_for_erase(boost::interprocess::offset_ptr<boost::multi_index::detail::ordered_index_node_impl<boost::interprocess::allocator<char, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index> > >, long, unsigned long, 0ul>, boost::interprocess::offset_ptr<boost::multi_index::detail::ordered_index_node_impl<boost::interprocess::allocator<char, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index> > >, long, unsigned long, 0ul>&, boost::interprocess::offset_ptr<boost::multi_index::detail::ordered_index_node_impl<boost::interprocess::allocator<char, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index> > >, long, unsigned long, 0ul>&, boost::interprocess::offset_ptr<boost::multi_index::detail::ordered_index_node_impl<boost::interprocess::allocator<char, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index> > >, long, unsigned long, 0ul>&) ()
(gdb)

Oh, what do i do with it now? =)))

6

I think you should collect the relevant information and get in touch with upstream. SIGBUS is ver rare on x86[_64] and if it happens, there’s usually something non obvious going on.

Just to be on the safe side. Can you check if there are any apparmor denials in dmesg log?

7

Just this

[230935.824370] audit: type=1326 audit(1548297172.367:8377): auid=1000 uid=0 gid=0 ses=3 pid=19933 comm="vizd" exe="/snap/vizd/x5/bin/vizd" sig=0 arch=c000003e syscall=43 compat=0 ip=0x7fbaefe1976d code=0x7ffc0000
8

$ scmp_sys_resolver 43
accept

Seems you likely need to plugs the network-bind interface.