search

ReactiveDrop / reactivedrop_public_src

Alien Swarm: Reactive Drop game source code and issue tracker.
https://reactivedrop.com
124 stars 36 forks source link

Crash with too many entities #655

Open qq578023708 opened 1 year ago

qq578023708 commented 1 year ago

https://github.com/qq578023708/RdCrashFiles

BenLubar commented 1 year ago

A few of these are challenges or maps that are spawning too many entities (those are the ones with the engine version number in the filename at the top of the list).

I've gone through five of the ~350 remaining crash dumps and they're identical materialsystem.dll access violations that happen at an instruction pointer ending with 4cbe (address space layout randomization means the first four digits are different for each run of the program).

Not sure why the dedicated server is running any of the shader code, but I definitely need to dig into this and figure out what's going on.

BenLubar commented 1 year ago

I noticed you have -num_edicts 8192 in your command line - that's not going to do anything, that's a goldsrc command and the edict limit is hard-coded into the engine and networking code in Source.

qq578023708 commented 1 year ago

Can the problem of generating too many entities be automatically destroyed or suppressed? For example, if an alien spawning point generates aliens infinitely, and they are unable to reach the player's position and these aliens are not killed, they will continue to spawn unrestricted, ultimately causing the server to crash

BenLubar commented 1 year ago

Alien spawners have limits on how many spawned aliens they can have at a time, even if they have an infinite supply of aliens. Since one of the crashes was from running out of string table space and there are only 6 entity limit crashes out of hundreds of crashes you uploaded, I'm tempted to believe that it's just one challenge on one map that's actually hitting the limit (since different maps have different amounts of entities spawned at the start).

BenLubar commented 1 year ago

Ok, so I've found an easier way of reproducing the materialsystem.dll crash:

  1. open model viewer
  2. close model viewer

now I just need to figure out what's going on in this code I have no access to

BenLubar commented 1 year ago

The materialsystem.dll crash appears to only happen at engine shutdown, so it's only crashing when the server is already exiting. Still no idea what's causing the corruption but it's definitely memory corruption in a material object.

mithrand0 commented 1 year ago

Material crash has been fixed in commit #6fb810d6f4efacd6695c91673700a2277

mithrand0 commented 11 months ago

The material crash has been fixed, changed the title a bit to reflect the entity issue.