That was me. I hit report a few more times but I guess the call stack isn't helping? I'm not sure what other info is relevant. I was grinding out XP blockading at Marquette Alpha, with toasts turned off (so I can hit blockade 50 times quick without getting a pile of toasts to wait for when an encounter happens). Seems to happen even if I do it slow, and it's very intermittent (maybe once every 100-200 times). Looks like a result from some particular dice roll outcome for the Blockade action that doesn't happen often.
It must have been introduced recently though, because I didn't see it before getting the update with the new ship upgrades. Is it my shiny new Hyperion Superstructure?
I don't see anything wrong after the crash happens -- the same seems to be exactly where it was before the crash, as if the errant Blockade never happened.
Post by Cory Trese on Jul 27, 2011 13:01:17 GMT -5
What is happening in the stack trace is that the combat system and the blockade thread are running at the same time. I am not sure why that would happen, but I had added some additional locks / blocking mutex type stuff to stop it. Hopefully it will slow down the blockade event stream.
The only error we had reported (including the BOOM BOOM one) is the database blocked error, so I don't think it is the upgrade or the update.
The issue was certainly injected when I started reading the database to update the status text on the bridge menu.
Ah, that explains it. This blockading was "speed play" where I was mashing Blockade repeatedly and quickly, so I can see how that might cause some race conditions when toasts are turned off.
A few times I have had encounters while Blockading like this, where the result of the battle gets lost (i.e. cargo I looted disappears). That is probably related -- combat results and a Blockade result conflicting, and the Blockade result winning out over the combat.