Interestingly, there seems no freeze loop when disabling debug in everything the main module with the actual program content. I'm it seems like that because I know how rarely and how sudden this freez could happen. But since I can't simply say anything about the other code beeing wrong, it has to be something in the debug system. I mean the only thing this debug system does is change the scheduling and the delays between action - but exactly this is what worked well before! So I can't help, but is related to the debug system. Well, atleast something I can focus on. Should do some more tests one this - in a seperate test file to keep the actual code from running properly. At last, I fixed a few things that would eventually become a problem. The more I think about it, the more I'd prefer to write a more specialized, event-based system one day. But not this time since it requires way too much work to keep it in time with the bachelor thesis, the game creation itself and so on. However, the thus lasting segfault always happens after attempting to schedule a release task the second time on the same ressource after doing the same on the first ressource. It could be the hash array, though... Yeah, I haven't tested it thaaat exactly, only the correctness of it's output compared to the input in a very controlled 1-N value range, not random thread identifiers. Hm. Excluding the debugging or limiting it to non-colliding threads with one-time use will not result in any problem. But wait, debug messages also come when entering and exitting functions - maybe this has to do with it, too.... Let's see about that. I can think of it beeing a problem involving parallely debugging threads - ultimately doing something false that will result in overwriting of values.

No comments: