Android version crashing when loading gzipped images for the first time #484
Comments
|
That indeed isn't making much sense since zip and gzip are using a totally different method (first one extracts to temp, second one is read directly), but they do use the same ZLIB library of course.. And I can't reproduce it with desktop either, so the only thing that could ease the pain is a proper stack trace of the crash. Also I'm in the middle of updating the codebase to 3.7 (and almost finished), so juggling with many hot plates isn't too fun. |
|
Is there any new directory created, or something that changes when a .crt file is opened for the first time? Because now after that, the only way I can get the error to reappear again is to install RetroArch on another Android phone. And this is across all the VICE cores, regardless in which core I opened up the .crt file. I'll try later this week to see if this can be "fixed" by loading something other than a zipped .crt. Unfortunately I'm not familiar at all with Android development or how to do a stack trace on a phone. I'll see if there's a usable x86/x64 Android which runs in Vbox/VMware with not too much hassle, just to see if I can rule out ARM being the cause of this. |
|
As the log says, the extraction happens under But again, that should not matter in any way with gzipped files, since they are not extracted to that temp dir.. And no, nothing happens with crt files alone, only zips and 7zs, and it does not matter what is inside. |
I checked all directories by looking at the time stamps. Only thing I found that changed, is that a /storage/emulated/0/RetroArch/saves/Commodore - 64/TEMP directory was created which didn't previously exist. If this is the cause, it should be easy to check by doing an mkdir TEMP before running RetroArch the first time. I'll update once I tried that. |
|
But hot damn, it does matter. I tried removing the temp dir and d6z no longer starts.. I guess I'll have to fix that in the current version then since it can be reproduced. |
|
Hah, the internal method does actually want to extract it after all, but via the archdep method that I've redirected to use the same common temp dir, because snapshots when using tapes wanted to use the temp for extracting tape data, which I have disabled. Which means the fix was trivial and coming right up. |
RetroArch has plenty of general issues with random crashes on my Nvidia Shield when using the UI and what not. I've had some spare time lately so Idecided to try to find what's causing the crashes, and decided to start with the VICE cores, as they have some extraordinary issues which doesn't seem to plague most of the other cores I've tried on the Nvidia Shield.
It took me a while but I finally managed to pinpoint it. I've confirmed this also happens on a freshly installed RetroArch on an Android phone.
Steps to reproduce:
Log file no. 1: Opening a .d6z image file on a freshly installed RetroArch
App crashes
Log file no. 2: Opening the next .d6z image file in the list
App crashes
Log file no. 3: Opening a zipped .crt file
Game runs
Log file no. 4: Opening the .d6z image file that previously caused RetroArch to crash
Game runs
In the examples above I used the c128 core, which because I wanted to see if it was reproducable regardless if I used the x64sc, x64, xscpu and x128 variants. And it was.
The text was updated successfully, but these errors were encountered: