lerptag: Ensure we never return uninitialized data

[DolceTriade]

If for any reason, we fail to find a tag for iqm/md5 code, if the attachment is uninitialized like in the entity cache code, we will return NaNs.

The md3 code path already did this, so pull it out of that path and do it globally so iqm/md5 code gets it too.

Fixes this crash for me:

#0  0x00007fff82ecac27 in Math::Clamp<float> (value=nan(0x7fbd90), min=100, max=nan(0x7fbd90)) at /mnt/media/code/unv-master/daemon/src/common/Math.h:43
#1  0x00007fff82fa93cb in DrawTracer (source=0x7fffb27faf10, dest=0x7fff83685678 <cg_entities+517576>, chance=1, length=200, width=3) at /mnt/media/code/unv-master/src/cgame/cg_weapons.cpp:2337
#2  0x00007fff82fa9838 in CG_HandleWeaponHitWall (es=0x7fff83684f60 <cg_entities+515760>, origin=0x7fff83685678 <cg_entities+517576>) at /mnt/media/code/unv-master/src/cgame/cg_weapons.cpp:2631
#3  0x00007fff82f055be in CG_EntityEvent (cent=0x7fff83684f60 <cg_entities+515760>, position=0x7fff83685678 <cg_entities+517576>) at /mnt/media/code/unv-master/src/cgame/cg_event.cpp:1083
#4  0x00007fff82f08134 in CG_CheckEvents (cent=0x7fff83684f60 <cg_entities+515760>) at /mnt/media/code/unv-master/src/cgame/cg_event.cpp:1450
#5  0x00007fff82f92fba in CG_TransitionEntity (cent=0x7fff83684f60 <cg_entities+515760>) at /mnt/media/code/unv-master/src/cgame/cg_snapshot.cpp:80
#6  0x00007fff82f92d92 in CG_TransitionSnapshot () at /mnt/media/code/unv-master/src/cgame/cg_snapshot.cpp:183
#7  0x00007fff82f92456 in CG_ProcessSnapshots () at /mnt/media/code/unv-master/src/cgame/cg_snapshot.cpp:437
#8  0x00007fff82f9e63f in CG_DrawActiveFrame (serverTime=388400, demoPlayback=false) at /mnt/media/code/unv-master/src/cgame/cg_view.cpp:1837
#9  0x00007fff82ed9a86 in VM::VMHandleSyscall(unsigned int, Util::Reader)::$_5::operator()(int, bool) const (this=0x7fffb27fb917, serverTime=388400, demoPlayback=false) at /mnt/media/code/unv-master/src/cgame/cg_api.cpp:89
#10 0x00007fff82ed9a52 in Util::apply_impl<VM::VMHandleSyscall(unsigned int, Util::Reader)::$_5, std::tuple<int&&, bool&&>, 0ul, 1ul>(VM::VMHandleSyscall(unsigned int, Util::Reader)::$_5&&, std::tuple<int&&, bool&&>&&, Util::seq<0ul, 1ul>) (func=...,
    tuple=...) at /mnt/media/code/unv-master/daemon/src/common/Util.h:136
#11 0x00007fff82ed99fd in Util::apply<VM::VMHandleSyscall(unsigned int, Util::Reader)::$_5, std::tuple<int&&, bool&&> >(VM::VMHandleSyscall(unsigned int, Util::Reader)::$_5&&, std::tuple<int&&, bool&&>&&) (func=..., tuple=...)
    at /mnt/media/code/unv-master/daemon/src/common/Util.h:141
#12 0x00007fff82ed990a in IPC::detail::HandleMsg<VM::VMHandleSyscall(unsigned int, Util::Reader)::$_5, IPC::Message<IPC::Id<(unsigned short)0, (unsigned short)3>, int, bool>, IPC::Reply<> >(IPC::Channel&, IPC::SyncMessage<IPC::Message<IPC::Id<(unsigned short)0, (unsigned short)3>, int, bool>, IPC::Reply<> >, Util::Reader, VM::VMHandleSyscall(unsigned int, Util::Reader)::$_5&&) (channel=..., reader=..., func=...) at /mnt/media/code/unv-master/daemon/src/common/IPC/Channel.h:217
#13 0x00007fff82ed84e0 in IPC::HandleMsg<IPC::SyncMessage<IPC::Message<IPC::Id<(unsigned short)0, (unsigned short)3>, int, bool>, IPC::Reply<> >, VM::VMHandleSyscall(unsigned int, Util::Reader)::$_5>(IPC::Channel&, Util::Reader, VM::VMHandleSyscall(unsigned int, Util::Reader)::$_5&&) (channel=..., reader=..., func=...) at /mnt/media/code/unv-master/daemon/src/common/IPC/Channel.h:241
#14 0x00007fff82ed7c25 in VM::VMHandleSyscall (id=3, reader=...) at /mnt/media/code/unv-master/src/cgame/cg_api.cpp:88
#15 0x00007fff830b6f75 in CommonInit (rootSocket=66) at /mnt/media/code/unv-master/daemon/src/shared/VMMain.cpp:82
#16 0x00007fff830b6b6a in vmMain (rootSocket=66) at /mnt/media/code/unv-master/daemon/src/shared/VMMain.cpp:153
#17 0x000055555596e2c9 in VM::CreateInProcessNativeVM(std::pair<IPC::Socket, IPC::Socket>, Str::BasicStringRef<char>, VM::VMBase::InProcessInfo&)::$_0::operator()() const (this=0x55557f9a68b8)

[illwieckz]

Maybe the fix for that issue?

• IPC timeout reported on mod, don't know yet if the bug is in upstream or not Unvanquished/Unvanquished#3511

People report disconnections, and a VM crash would do that.

[DolceTriade]

Unlikely. I would expect to see a crash dump in that case.

[slipher]

LGTM

So does this look like a pre-existing bug that was triggered by the skeleton re-shuffling? Apparently this non-existent tag case always happens for the rifle, another gun that I forgot, and some buildables. I don't understand what's even supposed to happen when the tag is not found.

Maybe the fix for that issue?

• IPC timeout reported on mod, don't know yet if the bug is in upstream or not Unvanquished/Unvanquished#3511

People report disconnections, and a VM crash would do that.

Unlikely. I would expect to see a crash dump in that case.

With a release build this should not cause any (immediate) halting, just a possible NaN propagating. Mod hosters could be building with asserts which should indeed cause a crash dump.