iScriptException ...

Something uncomfortably wrong occurs in the game engine. Objects I'm trying to restore have invalid state attached. I believe this is the reason why there has been "guru meditation" screens during last playtests with friends. It seems linked to abnormal use of the memory: while the infringing object seems to have proper structure, it seems linked to a state that is absolutely not looking like a state structure, but rather some animeds content...
That could quite match with some earlier dig into the issue where I had invalid pointers at some delete() operators, leading to red "guru meditation" screens. I unpacked my gdb-remote-analyzers-and-setup-perl scritps. It takes ages to launch the game in that fashion, but I should get a list of stack trace for those locations that shouldn't have been released. I may need to find a proper path to reproduce the issue first.

Meditate on this I will...

3 days later, with 2 runs on the first level, I managed to trigger the exception again in the "demulator", producing 1GB worth(?) of log. I have hopefully a shorter summary of the 11 addresses involved in operations that looked suspicious. I need to program the software eyes that will scrutinize those operations and explain what happened.

2 more days and "PERL's eyes" are ready. I get detailed reports with stack trace of the last allocation, the last sound deletion and the offending "double-free" issue. But what should I think about some memory block that is first allocated in "GobState::addOnDone" (thus should be a transition, somehow, or the vector of transitions), gets deleted as GobState is destroyed, and then destroyed again as a GobAnim ?_?

Finally, one object, shot during some state transition is delete twice, with a time locality pattern that makes it look like a real issue, not some side-effect. Both deletion happens during Engine::animate(), likely at a few frames interval. How has that occured ?

What transition create that object ? What object is it ? Which object created it ? ... At least those questions can be answered with the whole recording of memory allocations. I know from stack trace the address of the transition that created the "faulty" object. From there, running "Perl's eyes" once again, I find it belongs to a "fall->hit" transition of Bilou, and the object generated is a "power-down" object. That might help reproducing the error ... tomorrow.

Question: while there has been only one "constructor" call, could there be two "reganim", making the object linked twice in the objects list ?
Question: if there's a single "reganim" for two "delanim", what is the cause ? Who messed up with the list's invariant ?