[fixed][d*x][03/21/15] Homing missiles crashes
Runtime Crash in a 1v1 match d1x-rebirth-032115.exe By having the host shoot a homer at 2nd client in the main room of Logic.

[Image: BetaHomercrash.png]

Demo file: https://dl.dropboxusercontent.com/u/1022...mpdemo.dem

Update1: host can shoot the homing missile when I am not around, and It can lock on me afterwards, but if he initiates the launch and it locks at the same time, it crashes.

Update2: having a non host shoot a missile, the lockee always crashes, regardless of who is host.
In this same game, I was using a Linux build and I was the host. When one of the non-hosts fired a homer at the other one, it crashed for both me and the one being shot at.

I got this error in terminal:
terminate called after throwing an instance of 'valbaseptridxutil_t<object, short>::index_range_exception'
  what():  invalid index used in array subscript
Aborted (core dumped)
More testing confirmations.
In a 3 player game, this happens as follows.

[glow=red,2,300]HOST [/glow] ~(homing>      PLAYER: The player crashes, and the other player may crash (not confirmed)

PLAYER ~(homing>    [glow=red,2,300]HOST [/glow]:  Nothing happens.

PLAYER ~(homing>    PLAYER: Both player and host crash.
Thanks for letting me know. Due to the code refactoring, these things are prone to show up. So, please do expect more of these for the time being - we are still working on that. Smile
The greatest pleasure in life is to do what people say you cannot do.
Uhm... Honey, there's a head in the toilet!
(03-22-2015, 08:27 PM)A Future Pilot link Wrote: I got this error in terminal:
terminate called after throwing an instance of 'valbaseptridxutil_t<object, short>::index_range_exception'
  what():  invalid index used in array subscript
Aborted (core dumped)
An objptridx_t (or similar) was constructed with an index that is not valid for Objects[].  If the type is objptridx_t, it can accept object_none or a valid index.  If the type is vobjptridx_t, it can only accept a valid index.  A backtrace would be handy, but since you provided good steps to reproduce, I can try to reproduce it locally to get a backtrace.

[Edit: backtrace follows.  It looks a bit different from the reported problem, but I think it is because I have d_debugbreak enabled, so it trapped sooner.  This was produced in a cooperative game where one player fires a homing missile at a robot, and the non-firing player crashes.  As in the initial report, firing a homing weapon that initially has no lock is fine.  Firing a homing weapon that locks immediately will crash the non-firing player.]

#0  0x00005555557cd08a in d_debugbreak () at common/include/dxxerror.h:96
#1  objnum_remote_to_local (owner=255, remote_objnum=-8231) at similar/main/multi.cpp:266
#2  multi_do_fire (buf=<optimized out>, pnum=1) at similar/main/multi.cpp:1481
#3  multi_process_data (pnum=pnum@entry=1, buf=<optimized out>, type=<optimized out>) at similar/main/multi.cpp:5024
#4  0x00005555557cdceb in multi_process_bigdata (pnum=pnum@entry=1, buf=buf@entry=0x7fffffffc2c2 "\003\001e", len=len@entry=21) at similar/main/multi.cpp:2315
#5  0x00005555558d0119 in net_udp_process_mdata (data=data@entry=0x7fffffffc2c0 "\021\001\003\001e", data_len=data_len@entry=23, sender_addr=..., needack=needack@entry=0) at similar/main/net_udp.cpp:4884
#6  0x00005555558d1f70 in net_udp_process_packet (data=data@entry=0x7fffffffc2c0 "\021\001\003\001e", sender_addr=..., length=<optimized out>) at similar/main/net_udp.cpp:2911
#7  0x00005555558d4c1d in net_udp_listen () at similar/main/net_udp.cpp:4292
#8  0x00005555558d9c72 in net_udp_do_frame (force=<optimized out>, listen=<optimized out>) at similar/main/net_udp.cpp:4454
#9  0x00005555557b0694 in multi_do_frame () at similar/main/multi.cpp:848
The remote_objnum=-8231 looks bad, and the Int3 that trapped is marked with a comment stating the value is illegal, followed by returning it anyway.
New findings, You can shoot host He will crash. BUUUT If you are not directly looking at the fire barrel and you dont get a lock, it will not crash at all. You have to be LOOKING and getting locked on at the same time it leaves the barrel. If you look away you don't crash, If you watch the barrel while it shoots but it does not lcok at 1st, you will not crash.

This is a very interesting and particular bug.
Looking at the code, I cannot see how this would ever work. Smile  This looks like fallout from an improper implementation of Drakona's "sniper packets" feature (which, although invented by her, was not committed to Rebirth by her, so do not blame her for this bug).  In 0.58.1, MULTI_FIRE is a very simple message.  The important part is that it has the target's index at [6,7] in the message.  After 0.58.1 (but not specifically related to unification), it was split into several messages, depending on the exact weapon fired and its state.  With sniper packets, [6,7] is the low portion of the shooter's X coordinate and the target index is moved to [18,19], but the parsing code still expects it to be at [6,7].  This kind of mismatch is why I started converting things to the serialization header, which handles packing and unpacking in a single definition, so adding elements cannot desync the generator/parser.  When the missile starts without a lock, the game uses MULTI_FIRE instead of MULTI_FIRE_TRACK.  The crash is specific to a field only sent with MULTI_FIRE_TRACK, which is why a missile launched without lock does not cause a crash.
Fix parsing of MULTI_FIRE_TRACK/MULTI_FIRE_BOMB resolves the homing weapon crash for me.

Forum Jump:

Users browsing this thread: 1 Guest(s)