Operations continue on server after client crash

[Sean Ryan]

After dying from Gorun ( on crimson ), ember crashes. Stack trace for this is below.

Where this gets strange is AFTER logging back in, the player is teleported to the graveyard ( which is good ), however I have noticed that the player is still attacking. More along this line, when getting back into Gorun's perception range again, he immediately resumes attacking.

It looks to me like the client StoppableTask ( in this case strike ), appears visually on inspection to be continuing just fine. I have not been able to trace yet what is happening, however I suspect that the MeleeTask becomes active and never stops. Even though the client crashed/died/respawned the task seems to have lived on.

data/rulesets/deeds/scripts/world/objects/tools/Melee.py

Maybe in the tick() operation the usage.is_valid() does not handle this case, or perhaps because in the do_strike() the check for if the target parent is destroyed ( respawned character seems to have nothing targetted ).

sryan@pandora-vm:~/code/wf/work/local/bin$ ./ember --debug
Starting Ember in debugger....
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Starting Ember version 0.7.2-1100-g108ebabd9 with prefix '/home/sryan/code/wf/work/local'.
Setting config directory to /home/sryan/code/wf/work/local/etc/ember/
Writing logs to /home/sryan/.local/share/ember/ember.log
[New Thread 0x7fffeca28700 (LWP 115026)]
[New Thread 0x7fffec227700 (LWP 115027)]
[New Thread 0x7fffeb761700 (LWP 115028)]
[Thread 0x7fffeb761700 (LWP 115028) exited]
[New Thread 0x7fffeb6e0700 (LWP 115029)]
[Thread 0x7fffeb6e0700 (LWP 115029) exited]
[New Thread 0x7fffeb6e0700 (LWP 115030)]
[New Thread 0x7fffeaedf700 (LWP 115031)]
[New Thread 0x7fffea4b7700 (LWP 115032)]
[New Thread 0x7fffcbfff700 (LWP 115033)]
[New Thread 0x7fffcb7fe700 (LWP 115034)]
[New Thread 0x7fffcaffd700 (LWP 115035)]
[Thread 0x7fffcaffd700 (LWP 115035) exited]
[New Thread 0x7fffcaffd700 (LWP 115036)]
[New Thread 0x7fffca5f8700 (LWP 115037)]
[New Thread 0x7fffc9869700 (LWP 115059)]

Thread 1 "ember.bin" received signal SIGSEGV, Segmentation fault.
0x0000555555b04831 in std::default_delete<Ember::IEntityAttachment>::operator() (this=0x55555e047780, __ptr=0x55555f1134d0) at /usr/include/c++/8/bits/unique_ptr.h:75
75 operator()(_Tp* __ptr) const
#0 0x0000555555b04831 in std::default_delete<Ember::IEntityAttachment>::operator() (this=0x55555e047780, __ptr=0x55555f1134d0) at /usr/include/c++/8/bits/unique_ptr.h:75
#1 std::unique_ptr<Ember::IEntityAttachment, std::default_delete<Ember::IEntityAttachment> >::reset (__p=0x55555f1134d0, this=0x55555e047780) at /usr/include/c++/8/bits/unique_ptr.h:382
#2 std::unique_ptr<Ember::IEntityAttachment, std::default_delete<Ember::IEntityAttachment> >::operator= (__u=..., this=0x55555e047780) at /usr/include/c++/8/bits/unique_ptr.h:289
#3 Ember::EmberEntity::setAttachment (this=0x55555e047250, attachment=...) at /home/sryan/code/wf/work/source/worldforge/clients/ember/src/domain/EmberEntity.cpp:389
#4 0x000055555599af90 in Ember::OgreView::World::View_topLevelEntityChanged (this=0x55555dc01fe0) at /usr/include/c++/8/tuple:919
#5 0x00007ffff7de4bd2 in sigc::internal::signal_emit0<void, sigc::nil>::emit (impl=0x55555dc02130) at /usr/include/sigc++-2.0/sigc++/signal.h:798
#6 sigc::signal0<void, sigc::nil>::emit (this=<optimized out>) at /usr/include/sigc++-2.0/sigc++/signal.h:2804
#7 Eris::View::setTopLevelEntity (this=<optimized out>, newTopLevel=<optimized out>) at /home/sryan/code/wf/work/source/worldforge/libs/eris/src/Eris/View.cpp:408
#8 0x00007ffff7de5dd3 in Eris::View::update (this=0x55555dbe8ae0) at /home/sryan/code/wf/work/source/worldforge/libs/eris/src/Eris/View.cpp:121
#9 0x00005555557c5490 in Ember::Application::mainLoop (this=0x7fffffffdc60) at /home/sryan/code/wf/work/source/worldforge/clients/ember/src/main/Application.cpp:333
#10 0x00005555557c6b10 in Ember::Application::start (this=this@entry=0x7fffffffdc60) at /home/sryan/code/wf/work/source/worldforge/clients/ember/src/main/Application.cpp:550
#11 0x00005555557af271 in main (argc=<optimized out>, argv=<optimized out>) at /home/sryan/code/wf/work/source/worldforge/clients/ember/src/main/Ember.cpp:173
A debugging session is active.

        Inferior 1 [process 115022] will be killed.

[Erik Ogenvik (erik-ogenvik)]

Thanks for the report.
The Ember issue should not happen, so I need to investigate how it can be.

There are two separate bugs on the server.
One is that the AI should both stop attacking as well as stop holding a grudge to a character after it has been killed.
The other is that tasks should stop when a character is killed. The effect you're seeing of the character continuing the attacks is because that task never stopped.

[Sean Ryan (sryan)]

I got a bit better trace below and a few more pieces of information ( I am annoyed that I can't dig more because a lot of the values are optimized out ).

New Info 1:
    This happens every time I exit. So lauch, then click exit, and quit. Crashes every time.

New Info 2:
    The movable object is ok in this scenario, but the I->Movable is definitely not ok. I is an attachment point reference.

New Info 3:
    I stepped through the exit process 4 separate times breaking on src/components/ogre/model/Model.cpp:714 ( one frame up from where the crash happens ) and it exited normally every single time.

If I had to make a guess, i would say that it looks like since attachPoints is reference, that external to here the dereferenced object is probably deleted first in the teardown maybe in another thread or something. It gets a bit murky here, but only when I trap in the lowest frame, can i see the segv, never if I go up one. Gotta be some sort of race condition, relating to the attachment points or maybe the attachment point wrapper.

src/components/ogre/model/Model.cpp:770
Ember::OgreView::Model::Model::detachObject
770: if (I->Movable == movable) {

<error reading variable: Cannot access memory at address 0x557431dad000><error reading variable: Cannot access memory at address 0x557431dad000>

#0 Ember::OgreView::Model::Model::detachObject (this=<optimized out>, movable=0x55b50eef8dc0) at /home/sryan/code/wf/work/source/worldforge/clients/ember/src/components/ogre/model/Model.cpp:770
#1 0x000055b5002d908b in Ember::OgreView::Model::Model::attachToNode (this=0x55b50e7edd30, nodeProvider=nodeProvider@entry=0x0) at /home/sryan/code/wf/work/source/worldforge/clients/ember/src/components/ogre/model/Model.cpp:711
#2 0x000055b5003061ad in Ember::OgreView::Model::ModelMount::~ModelMount (this=0x55b50e7ee0f0, __in_chrg=<optimized out>) at /home/sryan/code/wf/work/source/worldforge/clients/ember/src/components/ogre/model/ModelMount.cpp:48
#3 0x000055b5003061e9 in Ember::OgreView::Model::ModelMount::~ModelMount (this=0x55b50e7ee0f0, __in_chrg=<optimized out>) at /home/sryan/code/wf/work/source/worldforge/clients/ember/src/components/ogre/model/ModelMount.cpp:47
#4 0x000055b500307da3 in std::default_delete<Ember::OgreView::Model::ModelMount>::operator() (this=0x55b50e75c5f0, __ptr=<optimized out>) at /usr/include/c++/8/bits/unique_ptr.h:347
#5 std::unique_ptr<Ember::OgreView::Model::ModelMount, std::default_delete<Ember::OgreView::Model::ModelMount> >::~unique_ptr (this=0x55b50e75c5f0 = {...}, __in_chrg=<optimized out>) at /usr/include/c++/8/bits/unique_ptr.h:274
#6 Ember::OgreView::Model::ModelAttachment::~ModelAttachment (this=0x55b50e75c5a0, __in_chrg=<optimized out>, __vtt_parm=<optimized out>) at /home/sryan/code/wf/work/source/worldforge/clients/ember/src/components/ogre/model/ModelAttachment.h:60
#7 0x000055b500307df9 in Ember::OgreView::Model::ModelAttachment::~ModelAttachment (this=0x55b50e75c5a0, __in_chrg=<optimized out>, __vtt_parm=<optimized out>) at /home/sryan/code/wf/work/source/worldforge/clients/ember/src/components/ogre/model/ModelAttachment.h:60
#8 0x000055b5004c8ff4 in std::default_delete<Ember::IEntityAttachment>::op...