Segmentation fault in bitmap.cpp #150
Comments
|
For reference, that's this line: Line 864 in edb3f83 Might indicate that somehow |
|
#145 should fix this. Reiterating what's said in that PR, here's the exact sequence that happened:
To fix this, #145 uses signals to set the bitmap pointers to null when they're disposed. Those pointers are only used internally by their respective classes, so setting them to null shouldn't cause any problems. |
|
Wow that's a great analysis @WaywardHeart! Big thanks for fixing it. :) I'll cherry pick your commit into my fork since I need it soon-ish. |
|
If you're interested in patching the game in question to keep the sprites from staying on screen longer than they should (or fps drops, if the game's making a lot of them), then you can use this script to find out where the sprites in question are created (although it'll also make those problems worse in the process by preventing garbage collection of them altogether). Ruby 1.9's garbage collector was a lot more aggressive than Ruby 3's, so sprites that would only linger for a few seconds in RGSS can stick around for a while in mkxp. |
|
@WaywardHeart That script is for VX Ace with a link to a VX variant. Our game however is XP based so it wouldn't work. |
|
Ah, yeah, I suppose there are a couple problems with each version that wouldn't let it work out of the box with XP.Here's a heavily modified script I just made that should work for you. It uses object ids and finalizers instead of storing the objects themselves, so it doesn't prevent garbage collection like the previous one does. You'll need to either activate debug mode or disable the check at the top of the script to use it, and it works fine as a preload script. |
|
Okay I'm trying it. For now it throws this error. I might be able to debug and fix it tomorrow. |
|
@enumag Oh, right. That method doesn't work on class instances. Sorry about that, it should be fixed now. |
|
@WaywardHeart Yeah that works... but oh my it reports a ton of issues. 😳 How important is it to fix these? What impact does it have if these issues are not fixed? |
|
Once the segfaults are fixed, then just some potential fps drops until the GC gets to them. It's probably not a big deal unless you're making and discarding a ton of them in a short period of time, and I think your stuff is mostly just text, so... it's probably fine? Also, I fixed a problem with the viewport.dispose overload if you downloaded it within the past... 20 minutes or so. I saw that Pokemon Flux has a lot too, so it might just be a problem with the Essentials core scripts rather than anything you've done. |
|
I cherry picked your commit from #145 into my fork so we do have that fix applied in our game. Guess I don't need to worry about it too much then. |
|
Oh yeah I noticed those "is recycled object" errors in our logs too. If #149 fixes that then awesome! Yoink! 🙇 |
|
I've given it a bit more thought, and I think what's going on is you're just hiding the text when you're done with it. While I personally don't think that's a good practice, we don't make draw calls for them so it's not harmful. Even the bitmaps attached to them are probably only in the double-digit kilobytes at the most. I'd say it's safe to ignore them. |
|
Okay, I figured out what was going on. I was hooking the constructor (like the original script)... except mkxp doesn't generate the backend stuff until the initializer is called, and Essentials has some heavily used wrapper classes that never call it. Hook the initializer instead and the script reports almost nothing. Mystery solved! |
I managed to get a gdb backtrace of the segfault.
The text was updated successfully, but these errors were encountered: