Lockup on Move up after Move up

Submitted by chaos_star on Wed, 2009-04-29 14:04.
Project:Virtual Combat Cards Project
Version:0.92.2
Component:Code
Category:bug report
Priority:critical
Assigned:Nebulorum
Status:closed
Description

I was using v.91 last night in a game and a player used Guileful Switch. In order to change initiatives of the characters in question, I had to put everyone else on delay. As I was resuming normal turns and taking characters of delay, the program locked up. None of the buttons would work on anything. I took a screen shot of the error message that I will upload. It looks small but you can enlarge the picture and you should be able to read the text. Feel free to email me with any questions.

Ed P.

AttachmentSize
Doc2.doc120.5 KB

#1

Submitted by Nebulorum on Wed, 2009-04-29 16:59.
Title:Lock up» Lockup on Move up after Move up
Component:Miscellaneous» Code
Assigned to:Anonymous» Nebulorum

This is really a strange bug. I tried to reproduce it with the 0.91 version. Looking at the log, it's clear that combatant 7 moved up and then AL tried to move up while 7 was active (which is illegal). 7 should end the round prior to AL moves up.

However I could not reproduce this (and didn't have the real order between them) in my machine the buttons are never available. Could undoing and changing actions sort this out? Could you send me (via contact page) the encounter files.

I think this may be a race condition or something related to a delay between the UI sending the request and the action being executed. I have seen something like this when working on 0.92. Where you clicking quickly to move up several delayed combatants? Is your computer a multi-core machine?

Could you try version 0.92.1 and see if you can reproduced this?

#2

Submitted by Nebulorum on Fri, 2009-05-08 21:27.
Priority:normal» critical

Since this is still happening and we don't know what is happening. I believe exceptions will cause VCC to hang. This must be handled better and I believe this is relatively easy to do. This could improve the problem (allowing undos). I'll open a task for recording actions and log generation. But this will come after the new data formats.

#3

Submitted by Nebulorum on Fri, 2009-05-08 21:41.
Version:0.91» 0.92.2

I did some quick testing, and there are a couple of issues to handle:

  1. If there is an exception in the internal handling of an action, the core tracker will crash. This causes all further actions to fail. Including undo and redo.
  2. If a monster is delayed and dead it will fail to "auto-start" it's round. This causes and exception (and hang VCC);

To avoid this, the following changes will be implemented: catch exceptions to avoid crashing the core tracker, secondly fix the auto-start to handle with delaying monsters.

#5

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

Implemented a mechanism to catch exception on the internal event handling. If an exception happens the entire transaction is canceled. This is similar to having an undo.

This should avoid lockup's and allow Undo and redo to work. Once we can trace the step that caused this issue we should open a new issue.

#6

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

While I could not reproduce the double move up. The processing of invalid commands (like in the original post) should not cause lockup of the tracker.

#7

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

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