If the global state makes it segfault it'll probably do so in spring too, unless you mean it leaving a half-broken state when aborted? Well how complex are the libs that that could happen in? And how likely is this compared to just an error in the AI?
And it's not like infologs won't say "An AI crashed badly, spring might be unstable" stopping false bug hunts.
Attack of Save/Load functionality is back
Moderator: Moderators
Re: Attack of Save/Load functionality is back
I was describing how the engine could avoid being crashed by AI's, not how it could identify a crashed AI. Ignoring SIGSEGV would prevent the engine from crashing, but I am pretty sure you can't find out if the violation came from an AI.hoijui wrote:as i already described, this catches the signal process wide, which includes the engine and all of its AIs. capturing that only in the AIs is not possible as long as they are not running in separate processes, which is, as i said, never going to to happen cause it is to much work with practically no benefit. if you really want that AIs are unable to take down the engine, the best solution is to make a headless spring and run the AIs in a separate instance of the engine, which connects as a separate client.
-> less work & all fial safetly comes for free & we get a headless spring which is usefull for other stuff too
(Question: if you can print a stack trace on a crash, why can't you check the state of the program while it is running and determine if the access violation came from an AI?)
Re: Attack of Save/Load functionality is back
Java uses SIGSEGV, yes.
ther is a switch for hte JVM.. i dont remember what it was... ahh yeah i think it was JIT. anyway, when setting up the JVM to not use that stuff that uses SIGSEGV, it runs waaaay slower -> unusable.
i tested it back then.
this whole disscussion is quite pointless in my eyes.
if you know what you talk about, then tell us exactly how it shoudl work, but as nobody that wants htis fixed seems to know more/better then imbaczek or me, which say no go...
if there was a good way to do it, others would do it with native plugins. if that is hte case, bring it on, otherwise .. lets do more usefull stuff like... clenaing our noses by hand or something.
ther is a switch for hte JVM.. i dont remember what it was... ahh yeah i think it was JIT. anyway, when setting up the JVM to not use that stuff that uses SIGSEGV, it runs waaaay slower -> unusable.
i tested it back then.
this whole disscussion is quite pointless in my eyes.
if you know what you talk about, then tell us exactly how it shoudl work, but as nobody that wants htis fixed seems to know more/better then imbaczek or me, which say no go...
if there was a good way to do it, others would do it with native plugins. if that is hte case, bring it on, otherwise .. lets do more usefull stuff like... clenaing our noses by hand or something.
Re: Attack of Save/Load functionality is back
When a signal handler is entered one or two stack frames are overwritten. You can restore at least the IPs (don't know about the variables on stack and registers) with a lot of code though.eyu100 wrote:(Question: if you can print a stack trace on a crash, why can't you check the state of the program while it is running and determine if the access violation came from an AI?)
Maybe then you could jump back to the old location and pray stuff keeps working, or longjump to some point in the main loop, but I agree with hoijui: to me this all seems like a very bad idea. (code complexity, you're fixing symptoms instead of bugs, code quality, etc.)
Time would be better spent actually fixing the bugs or port the AI to Java or something. Or maybe even writing yourself a nice pipe/shared memory-based native AI interface.
