Lockup on Delay

Submitted by joeman on Fri, 2009-05-08 15:29.
Project:Virtual Combat Cards Project
Version:0.92.2
Component:Code
Category:bug report
Priority:critical
Assigned:Nebulorum
Status:closed
Description

Hey,

Delay caused program lockup again in my game tonight. The delayed combatant reached the top of the initiative order and then no more actions (including damage, heal, start round end round etc etc would work. Tried every button. Undo would not work either.

I think that it may be possible that a dead monster was removed automatically in the turn immediately prior to the delayed character. (now on the top of the list in the attached jpg.)

I tried to recreate the bug but couldn't.

Had an idea for delayed creatures tho, they should stay at the bottom of combatant order like reserved creatures, who can still be effected but who don't proceed up the initiative list. This makes sense from a practical point of view and may in the end fix bugs like this from happening in the future??

Thanks.

AttachmentSize
Frozen VCC after delay.JPG162.14 KB

#1

Submitted by Nebulorum on Fri, 2009-05-08 21:25.
Priority:normal» critical
Assigned to:Anonymous» Nebulorum
Status:active» duplicate

This seems to be a duplicate of #75: Lockup on Move up after Move up. I'm move the discussion there. We really need a simple way of reproducing this. You would not have a snapshot of the log?

#2

Submitted by Nebulorum on Sat, 2009-05-09 00:37.
Title:Delay bug occurred again» Lockup on Delay
Status:duplicate» fixed

This is somewhat different then issue #75: Lockup on Move up after Move up. It is clear that having exception in the event processing was causing lockups. This has been handled in the other issue.

As for the Delay problem, I was able to cause lockup by having dead combatants in delay. I believe there may be some other corner cases that cause exceptions in the tracker. I fixed the problem with the Dead Delaying combatants. With the new exception handling, lockups should stop. And undoing and redoing should allows us to get a better understanding of what is going on.

As for moving delaying combatants to the end of the list like the ones in reserve, this is not 100% compliant to the rules. Once a combatant delays we can go back in sequence before some other combatant. However if they don't move up before they come up, they loose the round. This is why they stay in sequence, unlike reserve you will not stay there forever.

With the new 0.92.3 release this should be fixed. Lets see if we get a clear reproducible situation. Another important thing is to include the log, and show the dead combatants when reporting bugs.

#3

Submitted by joeman on Sat, 2009-05-09 00:46.

Sorry, i posted the bug recreation in #75: Lockup on Move up after Move up as I thought you wished to move the discussion there. Therein lies the bug that happened in my game. Here it is again to keep this discussion flowing:

Hey,

I managed to recreate a bug I found in my game last night. I've attached the log file and a screen shot.

Here's how to do it:

1) load a party (monsters or PC's or both, doesn't matter)
2) start combat
3) delay combatant
4) start and end round of all combatants until delayed combatant is top of initiative order again.
5) give damage to any other creature on the list until they are "Dead!!!"
6) Bingo. Program is locked up.

This is different to having dead combatants in delay is it not?

Joe

AttachmentSize
Error log 03.JPG128.86 KB
Error log 03 Delay hang bug.txt2.03 KB

#4

Submitted by Nebulorum on Sat, 2009-05-09 01:06.
Status:fixed» patch (code needs review)

Thanks for an excellent write up. I manage to figure out what the issue is. And this is really a good catch for what was happening on #75: Lockup on Move up after Move up. So in the end it my be a duplicate. It's a race condition on the UI.

  1. When the delaying character is in the front of the sequence, you have to end round, then start.
  2. However because you where applying damage to the someone else, when you press the End Round the state changes on the first guy.
  3. Since he just lost his round the sequence does not get updated, which is correct.
  4. But since the sequence did not change, the End Round is not rechecked and is still available.
  5. You click on End Round a second time, and this causes an exception. On other version this crashed the internal processor.

The new release is immune to this type of crash, but I have to work on the "End Round" being incorrectly available.

#5

Submitted by Nebulorum on Sat, 2009-05-09 02:00.
Status:patch (code needs review)» fixed

Fixed the problem of End Round being incorrectly available.

#6

Submitted by joeman on Sat, 2009-05-09 02:37.

Tested this in version 0.92.3 & works fine for me now. Thanks!

#7

Submitted by Nebulorum on Fri, 2009-06-05 15:03.
Status:fixed» closed

Automatically closed -- issue fixed for two weeks with no activity.