Closed Eblo closed 2 months ago
I'll read the details once I'm signed into Matrix, but FYI there's another Disposable-related bug I ran into a few weeks ago (I have a tentative fix but didn't submit it yet). I'd be surprised if my bug is related to yours, since it looked like mine was tied to a screw-up I made when I implemented the hi-res mode, and I think it's in a code path that can only be reached when hi-res mode is enabled. However, the fact that there are apparently two different Disposable bugs in the codebase that evaded notice for many months seems to suggest that maybe we should be doing better QA testing for how Disposable stuff behaves. Is this something that we could easily automate the tests for...?
You can add #145 to your list of Disposable bugs. That and this both proved easily enough solved with some signals.
I doubt automated testing would help much, though. #145 and this both involve quirks of ruby's memory management, which can be a pain to reliably trigger even intentionally. And for #140 you just need to go through the binding files and add exception handlers to everything that looks like it could use one.
The tl;dr for this long-winded discovery is that mkxp-z does something with disposable objects that it shouldn't. The end result is an error similar to:
0072c193 and 959e9838 seem to be relevant commits. So far this has only been observed in RGSS1 games, which is consistent with the conditionals in those commits.
I'm not sure what the best fix is. Others have expressed interest in having these children automatically disposed for convenience. A configuration option may be a good medium for game compatibility.