Some games load, some don't (NES/FCEUmm Core)
-
One other interesting tidbit is that regardless of the zip file used (normally compressed file which fails to load or one using store [0% compression]), they both write the .nes file correctly to /tmp/retroarch -- same md5. It appears that something is continuing to read the original zip file.
-
@synack said in Some games load, some don't (NES/FCEUmm Core):
One other interesting tidbit is that regardless of the zip file used (normally compressed file which fails to load or one using store [0% compression]), they both write the .nes file correctly to /tmp/retroarch -- same md5. It appears that something is continuing to read the original zip file.
Yep, this is the bit that I can't understand. The zip file is being unzipped correctly in both cases. I added a comment saying that yesterday in the ticket that was raised. It makes no sense. Also my other fully update retropie setup is running all these roms fine. Same binaries, same kernel. It's madness :) I'll probably use that one, but I have put a lot more work into the one with the lr-fceumm issue. I might just rezip all my roms with 0 compression, but I'd really love to know what this issue is :)
-
just fyi, the issue has been identified and fixed
-
@synack That didn't fix the free crash on RetroPie (there was a separate issue though also) but I have debugged it and worked out the problem. Updating from source should sort it now. (binaries will be updated in a moment).
-
@BuZz Thank you. Appreciate the time and effort you put in to solve these type of issues.
-
Great work @BuZz!
Out of interest why do some zips work and others don't and why did zipping with 0 compression make the issue go away? Also, why could I not reproduce the issue on my other retropie setup that had the same retroarch and fceumm_libretro.so binaries?
-
@chromium Luck. Well, it was due to some code that after allocating some memory, tried to align a pointer. If the pointer got changed it would fail (since the wrong pointer would be used to free the memory). The code was wrong as the free should have been done on the original pointer value.
That's why when bisecting it, a completely unrelated piece of code in retroarch seemed to be the problem, as it just affected where the memory was allocated, but the real problem was the code that tried to align the memory block.
-
Pretty dang thrilled that this got fixed. Awesome sauce. Thanks @buzz for the troubleshooting.
-
I'll mark this thread as solved then unless somebody has reason not to...
-
I had been having this problem on PI3 and have been solving it by updating from Binary.
I am having these issues on Pi ZERO still.
i dont have a WIFI adapter, so what i have been doing is putting my SD card in a Pi 2 (since it uses the same retropie) and interestingly enough updating from binary fixed the LR-FCEUMM issue while in the PI2......but when i put the card back in my Zero, i get the same issues.
pretty stumped -
@jyo Pi2 and Pi Zero don't use the same image or RetroPie build mate.
Pi Zero is a Pi 1 in a smaller form factor.
I'd suggest opening a new topic with your details in as it is likely going to be a different fix for this.
-
@markyh444 oh wow you're totally right.
so i made the image for the pi 0/1.
but then im doing the update from binary in a pi2 since i couldnt get the wifi adapter i had to work.
shouldnt it be downloading the right file as its off the right image, or because the SD is in a pi2, it is downloading the files for a pi2/3? -
@jyo I dont know, but as i said you should open a new topic with details of your build etc.
I suspect it would be pulling Pi2 compatible files rather than 0 though, if it's in a Pi2 at the time...
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.