Closed ghost closed 7 years ago
Confirmed
[...]
xbox config: set sandbox (stub)
Signal 11 received
Backtrace elements: 6
#0 ./mcpelauncher(_Z12handleSignaliPv+0x62) [0x806cea5]
#1 [0xf7777bc0]
#2 ./mcpelauncher() [0x805cf98]
#3 ./mcpelauncher() [0x805d218]
#4 HYBRIS FileInterface::fread(void*, unsigned int, unsigned int, void*) const+53 in libminecraftpe.so+0x1849d85 [0xf5701d85]
#5 /lib/i386-linux-gnu/libc.so.6(+0x15c973) [0xf73c7973]
Dumping stack...
#19 HYBRIS FileInterface::fread(void*, unsigned int, unsigned int, void*) const+53 in libminecraftpe.so+0x1849d85 [0xf5701d85]
#476 HYBRIS FileInterface::fopen(std::string const&, std::string const&) const+78 in libminecraftpe.so+0x1849bfe [0xf5701bfe]
#492 HYBRIS FileInterface::fread(void*, unsigned int, unsigned int, void*) const+53 in libminecraftpe.so+0x1849d85 [0xf5701d85]
#500 HYBRIS EncryptedFileInterface::fopen(std::string const&, std::string const&) const+369 in libminecraftpe.so+0x184a8c1 [0xf57028c1]
Signal 6 received
./minecraft: line 3: 10396 Aborted ./mcpelauncher
Guessing the encrypted file interface is not implemented yet - hopefully it not that hard to fix
It crashes in libhybris while decoding a file pointer;
(gdb) bt
#0 0x0805cf98 in _get_actual_fp ()
#1 0x0805d218 in my_fread ()
problem is that the *fp is NULL, next step would properly be to override FileInterface::fopen and find out what it's trying to open
@guppy42 Help me in #143
I'm closing this issue and adding a todo to the wiki.
Found the same problem.
I patched the EncryptedFileInterface::fopen method to return 0, and it now appears to work.
Strangely, the first of the two strings passed in appears corrupt; I suspect it's not actually a string. The second is the name of a resource zip file, e.g. assets/assets/resource_packs/skins_premium/EverydayHeroes/content.zipe
I suspect that this bug is different to #143 or #79.
@phodopus42 Would you mind using my repository as a playground to help fix this issue? My fork
For whatever reason it tries to open "assets/assets/resource_packs/skins_premium/EverydayHeroes/content.zipe" (double assets/), I'll need to investigate.
Also, this double "assets/" issue is also why we don't have correct resource pack icons so I think what I actually need to do is workaround it.
Workarounded.
@kris27mc Thanks. I forked your repo in anticipation of doing some fixes.
I've done some digging, but I'm rapidly getting lost. It's loading the premium skin packs (which are encrypted zip files) and somehow injecting 'assets/' in the path twice.
The relevant bit of stack is:
MCMrARM has patched the hybris fopen call -- this is definitely a workaround.
I might have something to do with using 'assets' as a directory. I wonder if it's expecting the CWD to be that directory? I might try to continue digging, if it's of any use.
@phodopus42 The workaround definitely fixed the issue on my end. You're more than welcome to attempt to solve the root problem though. If you're interested, add an issue in my fork, and we can work on it from there
@phodopus42 I investigated it once to be a bug in MCPE itself, as on afaik all the platforms it uses some hack to get assets to load with custom paths (non-cwd). It was around half a year ago when I tried to track down the issue so I'll not use the exact symbol names as I don't remember them (the issue back then was just the resource pack icons not working properly so I just gave up). Apparently after resolving a valid icon ResourceLocation with the valid path, the code had to pass the path and resource path to the JSON (UI) binding system, however it called a "get full path" function (which appends assets/) instead of just getting the path string of the ResourceLocation, while still leaving the filesystem to be the asset one. I'd assume this case is similar and the same mistake has been made.
One option would be to patch that code to use the proper function but it seems like too much work to me, so I just left it as it is now. Another option is to extract the assets straight into the cwd, but it doesn't seem too cool either.
I had MCPE 1.1.2 running successfully under the 1.1 branch with the compatibility libs. Now using 1.1.3 with the current master branch, this is what I get, using the compatibility libs, as I only get an illegal hardware instruction as soon as I start it without the compatibility libs.
APK: com.mojang.minecraftpe 872010352.apk CPU & GPU: AMD