Beta builds crashing
#11
Yeah, I suppose this is related to the issue reported here: https://github.com/dxx-rebirth/dxx-rebirth/issues/50
The greatest pleasure in life is to do what people say you cannot do.
Uhm... Honey, there's a head in the toilet!
Reply
#12
For crash "here you go" at 08:24:39 PM, that is an internal consistency error.  Can you build 0.58.1-d1x with debug=1 and load logic.rdl there?  The original developers were somewhat bad about using assert to check that a level was consistent, but never enforced this in retail builds, so some popular levels are technically broken according to the assertions.

For crash "in D2" at 08:57:25 PM, robot_controlled[slot] was supposed to be a valid object number, but was not.  It looks like 0.58.1 and below would silently ignore invalid robot numbers:
Code:
    if ((objnum < 0) || (objnum > Highest_object_index))
    {
        Int3(); // See rob
        return;
    }
Now, passing an invalid number is fatal.
Reply
#13
Do you think that second crash is the one that has been happening usually? Because all of the crashes we were getting before were while playing co-op in D1 main mission. That one was co-op in D2 main mission.

And I know the crash didn't happen in 0.58.1 in logic. What do you want me to check there?
Reply
#14
All crashes tend to look alike unless you examine their stack trace or you get lucky with a unique exception string.  Coop games, on either D1 or D2, are probably susceptible to the robot_controlled[slot] crash.  If this is happening much, I can add a workaround to ignore the bad index until someone can fix the bug.

If you used the 0.58.1 posted on the site, that one has compiled out (removed) all assertions.  You would need to checkout 0.58.1 source and build with debug=1, then retest.

[Edit: on looking at the code, some sites check for object_none and some do not.  This is probably a bug that was hidden by the range check I posted above.  I will push a fix.]
Reply
#15
OK, so the invalid robot number has been fixed?

I'll use 0.58.1 with debug in logic today and see what happens. If it crashes I'll get you a backtrace. If it doesn't, what should I do?
Reply
#16
Yes, the invalid robot slot crash should be fixed in multi_robot_request_change: check robot_controlled[slot] for object_none.  I never reproduced the original crash, but the code was wrong not to check for object_none, so I added a check.  The code could still crash if a corrupted robot number is used, but that should only happen if there is a bug elsewhere.

If 0.58.1 with debug=1 crashes on logic, there is no need to get a backtrace.  That simply confirms that the level has never worked with assertions enabled.  If the level seems to play fine from a user perspective, then the assertions may be overly paranoid.  If the level has observable problems (e.g. impassable empty spaces, impossible corridors, etc.), then the assertions are right and the level is wrong.
Reply
#17
New backtrace:

D2X 04/19/15, custom level:
Code:
#0  0x00000000004af65f in d_debugbreak () at common/include/dxxerror.h:96
#1  multi_robot_request_change (robot=..., player_num=1)
    at similar/main/multibot.cpp:1191
#2  0x0000000000444608 in collide_robot_and_player (robot=...,
    playerobj=<error reading variable: Cannot access memory at address 0x1>,
    collision_point=...) at similar/main/collide.cpp:1031
#3  0x0000000000446e46 in collide_two_objects (A=..., B=...,
    collision_point=...) at similar/main/collide.cpp:2519
#4  0x00000000004c8327 in do_physics_sim (obj=...)
    at similar/main/physics.cpp:680
#5  0x00000000004c514d in object_move_one (obj=...)
    at similar/main/object.cpp:1742
#6  0x00000000004c60b8 in object_move_all () at similar/main/object.cpp:1876
#7  0x000000000045b33b in GameProcessFrame () at similar/main/game.cpp:1326
#8  game_handler (event=...) at similar/main/game.cpp:1109
#9  0x0000000000412500 in window_send_event (wind=..., event=...)
    at common/arch/sdl/window.cpp:206
#10 0x0000000000429183 in event_process () at similar/arch/sdl/event.cpp:163
#11 0x000000000040b02a in main (argc=<optimized out>, argv=<optimized out>)
    at similar/main/inferno.cpp:556
Reply
#18
Here's another one from the same level while trying to push through a small space:

Code:
#0  0x00007ffff63f24b7 in raise () from /usr/lib/libc.so.6
#1  0x00007ffff63f388a in abort () from /usr/lib/libc.so.6
#2  0x00007ffff6cddfcd in __gnu_cxx::__verbose_terminate_handler() ()
   from /usr/lib/libstdc++.so.6
#3  0x00007ffff6cdbe56 in __cxxabiv1::__terminate(void (*)()) ()
   from /usr/lib/libstdc++.so.6
#4  0x00007ffff6cdbea1 in std::terminate() () from /usr/lib/libstdc++.so.6
#5  0x00007ffff6cdc0b8 in __cxa_throw () from /usr/lib/libstdc++.so.6
#6  0x00000000004c96a6 in operator[] (i=0, this=0x7fffffffe548)
    at common/include/countarray.h:87
#7  do_physics_sim (obj=...) at similar/main/physics.cpp:464
#8  0x00000000004c514d in object_move_one (obj=...)
    at similar/main/object.cpp:1742
#9  0x00000000004c60b8 in object_move_all () at similar/main/object.cpp:1876
#10 0x000000000045b33b in GameProcessFrame () at similar/main/game.cpp:1326
#11 game_handler (event=...) at similar/main/game.cpp:1109
#12 0x0000000000412500 in window_send_event (wind=..., event=...)
    at common/arch/sdl/window.cpp:206
#13 0x0000000000429183 in event_process () at similar/arch/sdl/event.cpp:163
#14 0x000000000040b02a in main (argc=<optimized out>, argv=<optimized out>)
    at similar/main/inferno.cpp:556
Reply
#19
Re "D2X 04/19/15, custom level": In old times, it was silently ignored, but now triggers a debugger trap.  A player rammed a robot that had an invalid remote slot number.  I can make the check nonfatal, but I do not know why it would happen.  It might be caused by the "Hands-off period" set a few lines farther down, but that has always been there, so if that is the explanation, then the bug has gone unnoticed since at least 2001.

Re "small space": that appears to be an attempt to read from an array with no elements.  Again, that code has always been there, but the misuse was only promoted to a fatal error in December 2013.  I pushed Fix array overread to add a spot check to prevent the bad read.
Reply
#20
Looks like old crashes are fixed, but here's a new one (04/22/15 build):

Code:
#0  object_to_object_visibility (obj1=..., obj2=...,
    trans_type=<optimized out>) at similar/main/laser.cpp:975
#1  0x0000000000495736 in create_smart_children (objp=...,
    num_smart_children=9781272, num_smart_children@entry=6)
    at similar/main/laser.cpp:1994
#2  0x0000000000451a8c in object_create_badass_explosion (objp=...,
    segnum=..., position=..., size=<optimized out>,
    vclip_type=<optimized out>, maxdamage=1638400, maxdistance=1310720,
    maxforce=1638400, parent=...) at similar/main/fireball.cpp:293
#3  0x0000000000450cf6 in explode_badass_weapon (obj=..., pos=...)
    at similar/main/fireball.cpp:316
#4  0x0000000000445966 in collide_robot_and_weapon (robot=..., weapon=...,
    collision_point=...) at similar/main/collide.cpp:1683
#5  0x0000000000446dae in collide_two_objects (A=..., B=...,
    collision_point=...) at similar/main/collide.cpp:2515
#6  0x00000000004c8317 in do_physics_sim (obj=...)
    at similar/main/physics.cpp:680
#7  0x00000000004c513d in object_move_one (obj=...)
    at similar/main/object.cpp:1742
#8  0x00000000004c60a8 in object_move_all () at similar/main/object.cpp:1876
#9  0x000000000045b35b in GameProcessFrame () at similar/main/game.cpp:1331
#10 game_handler (event=...) at similar/main/game.cpp:1109
#11 0x0000000000412500 in window_send_event (wind=..., event=...)
    at common/arch/sdl/window.cpp:206
#12 0x0000000000429183 in event_process () at similar/arch/sdl/event.cpp:163
#13 0x000000000040b02a in main (argc=<optimized out>, argv=<optimized out>)
    at similar/main/inferno.cpp:556
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)