Crash shortly after loading a savefile

Issue #389 resolved
Former user created an issue

Reported by portponky who sent over the save file. Looks like a swarm enemy is in process of being destroyed as the game loads, which then crashes on this line:

parent->entities_to_destroy.emplace_back(this); // add this object to the queue for mop-up

ASAN:DEADLYSIGNAL
=================================================================
==20715==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000170 (pc 0x000001393510 bp 0x7ffd8ebd6e20 sp 0x7ffd8ebd65e8 T0)
    #0 0x139350f in std::__detail::_List_node_base::_M_reverse() (/home/norgg/gamedev/sphereface/bin/Linux64/Debug/sphereFACE_debug+0x139350f)
    #1 0x7c450b in void std::list<entity::base*, std::allocator<entity::base*> >::_M_insert<entity::ship::enemy::swarm*>(std::_List_iterator<entity::base*>, entity::ship::enemy::swarm*&&) /usr/include/c++/6/bits/stl_list.h:1771
    #2 0x7c450b in void std::list<entity::base*, std::allocator<entity::base*> >::emplace_back<entity::ship::enemy::swarm*>(entity::ship::enemy::swarm*&&) /usr/include/c++/6/bits/stl_list.h:1108
    #3 0x7c450b in entity::ship::enemy::swarm::destroy() /home/norgg/gamedev/sphereface/entity/ship/enemy/swarm.cpp:127
    #4 0x6157a7 in entity::base::damage() /home/norgg/gamedev/sphereface/entity/base.cpp:750
    #5 0x779cb9 in entity::ship::enemy::base::collided_with(entity::base*, boost::geometry::model::d2::point_xy<float, boost::geometry::cs::cartesian> const&, quaternion<double> const&) /home/norgg/gamedev/sphereface/entity/ship/enemy/base.cpp:113
    #6 0xb35a3d in sphere::check_collisions() /home/norgg/gamedev/sphereface/sphere.cpp:603
    #7 0xb36709 in sphere::update() /home/norgg/gamedev/sphereface/sphere.cpp:455
    #8 0xda8323 in universe::update() /home/norgg/gamedev/sphereface/universe/universe.cpp:684
    #9 0xc39574 in universe::loop_main() /home/norgg/gamedev/sphereface/universe/loop_main.cpp:54
    #10 0xbf94bf in universe::loop_dispatcher() /home/norgg/gamedev/sphereface/universe/loop_dispatcher.cpp:21
    #11 0x9bb66a in main /home/norgg/gamedev/sphereface/main.cpp:101
    #12 0x7f7b55b4e82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #13 0x415d88 in _start (/home/norgg/gamedev/sphereface/bin/Linux64/Debug/sphereFACE_debug+0x415d88)

Comments (12)

  1. Norgg

    Sigh, guess I wasn't logged in again.

    Anyway, did some poking around, looks like a swarm is being destroyed in a tunnel???

    Possibly moved into the tunnel on the same tick it was destroyed?

    Parent tunnel: 0x60e00000cd00
    Parent: 0
    
  2. Norgg

    I think they've always been able to, but it's rare because it'd have to be from a sphere you left them alive in?

  3. Norgg

    Oh, possible cause is if there was a hive on the exit to the tunnel, so it gets killed by the portal clearer and then the swarms instantly try to enter the tunnel but also get killed.

  4. Riot

    In any case, something is quite wrong here. The swarm thinks it's in a tunnel, but it's being destroyed because the parent sphere has it on its list.

  5. Norgg

    We could work around that specific case, but there's a general problem that anything that can enter a tunnel could get destroyed on that same frame and then have destroy called with no parent?

  6. Riot

    well that's what I'm confused about. Should that be possible? Does the act of moving to a tunnel change the parent pointers immediately? If so, the only correct solution is to add another queue, like the remove queue, which would only take them out of the sphere after the update loop.

  7. Norgg

    Yeah, portal::collided_with calls other->move_to_tunnel directly, which then clears the object's parent and puts it in the tunnel.

  8. Riot

    Guess we need to add another queue for moving things to and from tunnels, in each sphere, and passing to those rather than moving directly.

  9. Log in to comment