"Invalid Pointer" error when opening (some) zipped roms #4063
Comments
|
I have the same issue with a similar setup. When I unzip the roms, everythings runs fine. |
|
I've got a weird case of this to add to the pile... I have the exact same zip in two locations; a list of favorites in the root of the nes dir;
And then also in the larger group of all files;
The first location in nes/ gives an invalid pointer error, while the second in nes/!All/A/ works perfectly fine. If I unzip the file and zip it with 0% compression (aka store-only), then the error goes away. |
|
We need a stack trace of this, this isn't really telling us much. |
|
If you can point me at directions on how to do that, I'd be happy to give it a shot. edit: wait, managed to figure out a little bit in gdb if this is helpful at all: |
|
I'm getting this issue too and it is bizarre. I don't understand why zipping the non-working games with zero compression makes them work, but it does. In both cases the .nes is being unzipped correctly to /tmp/retroarch. Also if you put verbose output on you can see that information is being read from the rom in /tmp/retroarch before the invalid pointer exception. I have another retropie setup on a different SD card with EXACTLY the same versions of the retroarch and fceumm_libretro.so binaries and all the same .cfg and .sh files, the same kernel version and I don't have this issue there. |
|
The same issue here. Some zipped roms work, some don't. The problematic zipped roms used to work two weeks ago (with the raw retropie-4.1-rpi2_rpi3.img), I don't know what's changed (I've done a couple of system updates since that date). I tried fsck on my SD card and I also checked the zip files integrity, everything seems to be OK. If I unzip them, it works nice. If I zip them with a shorter name , it also works. |
|
I found the issue, it was a regression in the core and I have fixed it in libretro/libretro-fceumm@821ca02. |
|
I'm still getting the issue unfortunately even since @bparker06 patch - will bisect. |
|
@joolswills As a sanity check can you just confirm that the git version shown at the bottom-left of the RA menu is indeed 89ce055? |
|
Yes. It's related to the RetroArch version - I have it working with a build of RetroArch from a few weeks ago (currently bisecting). |
bisected to 9b2270f |
|
Can you get a backtrace of the crash? Or even better, a valgrind output as well? |
|
Yep. working on it. |
|
I guess there happen to be two separate problems at play here. I cannot reproduce the free() crash you're seeing, but the problems in the core were definitely real (and fixed my own crashes loading certain zips), so that's fun. |
|
|
Not sure if there is anything useful here (I don't have experience with valgrind - so feel free to ask me if you want another set of parameters) |
|
It looks like valgrind may be tripping on itself, it is dying with a completely different issue somewhere in ARM land. Can you try running under AddressSanitizer instead? Just |
|
See if this fixes anything - |
|
@bparker06 I suspected it wasn't that useful. Unfortunately SANITIZER=address doesn't seem to be much helper either :/ @twinaphex unfortunately not. do you want another backtrace after this libretro-fceumm change ? |
|
You could try giving me another backtrace, but I'm not sure if I can be of help. I think you should maybe try finding a fix for this yourself, we don't have your hardware. You know how to debug so you should be able to go from there. |
|
I may well - but best to start by feeding the information to you first no ? Also - I have limited free time along with my own projects etc. |
|
Fine, provide your other backtrace then, so far though I don't really see what the problem could be and you actually have the hardware and the ability to debug it. |
|
@joolswills This is from your pastebin - *** Error in `/opt/retropie/emulators/retroarch/bin/retroarch': free(): invalid pointer: 0x01ff8979 *** Can you find out which free function call this is happening on inside the RA codebase? |
|
I believe Although XBuf should only be freed if not NULL (and should be a valid pointer) |
|
The crash seems to go if I comment out this piece of code in src/video.c - some sort of alignment code ? |
|
yeah looks like a real mess. The nasty surprises just never end with some of these codebases |
|
Looks wrong anyway - because you can't free(XBuf) after incrementing it. If it's trying to allocate some aligned memory there must be a better way. |
|
@joolswills Perhaps XBuf was null at that point? |
|
@bparker06 It wasn't null as the free got called - it had been allocated, but then incremented - see the above for the faulty code. |
|
I meant, at the point XBuf is incremented, is it null? |
|
I don't think so as it wouldn't get that far. The code needs to save the original malloc address for the free and it should fix it (if the alignment code is needed for performance). |
|
eg (very rough - but it stops the crash). |
|
Try seeing if this fixes it - |
|
That works thanks, but it might be worth keeping the alignment code as it could have performance benefits ? (as with my example - saving the original pointer for use with free) but up to you. |
|
The malloc'ed memory would already be aligned so I think it's unnecessary. |
|
sounds good then. the only other thing is the change removes the check to see if the memory allocated ok which probably should be kept (and the check to not allocate if already allocated - are we 100% sure this doesn't ever get called again without calling FCEU_KillVirtualVideo ?) |
|
I put that check back already. |
|
ok great. so all good :) |
|
|
|
@bmn001 Let me know if this fix doesn't work for you, you need to update your copy of FCEUmm. |
|
Just wanted to chime in to confirm that yes, this update did indeed fix the problem I was seeing. Thank you so much to @twinaphex @joolswills @bparker06 and everyone else who helped for taking the report seriously and really digging in to discover what appeared to be a pretty obscure issue. I (and probably hundreds of silent other sufferers) will benefit from your work and we absolutely appreciate the effort. Thank you. |
|
Just to note - the alignment code actually makes quite a noticeable difference in performance when testing on armv6 (rpi1). On RPI1 on Super Mario without overclocking it's 45fps without and 50fps with. Still not fullspeed, but with the alignment code a small overclock is enough for fullspeed. I am going to put it back into retropie - (Obviously a working version so we free the correct pointer) - @twinaphex would you accept a working patch that includes the alignment code? Note that although @bparker06 said malloc already aligns - I guess it isn't optimal for the best performance in this case. (4 bytes aligned). |
|
Sorry I actually need to do more testing - I'm now not sure this code makes any difference so perhaps malloc aligns to 4 bytes anyway. It must be something else causing the performance difference I have seen - will do more testing. Sorry for the spam. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm running the latest compiled RetroArch with Retropie on a Raspberry Pi 3.
Some (not all) zipped roms will produce an "Invalid Pointer" error when I attempt to launch them from the command line:
*** Error in `/opt/retropie/emulators/retroarch/bin/retroarch': free(): invalid pointer: 0x01ff8979 ***
If unzipped, these roms launch without error. It's only when they're zipped that I run into trouble with some of them.
Here's an example of the error popping up within lr-fceumm:
http://pastebin.com/C36xN96W
And an example of a rom working properly in the same environment with the same launch command:
http://pastebin.com/7hwpgJxC
These zipped roms worked properly in previous versions of RetroArch. Maybe six months ago? Hard to say for certain.
I'm happy to provide any additional information you need to help track this down.
The text was updated successfully, but these errors were encountered: