MCMrARM / mcpelauncher-linux

Please note this is a legacy repository, please go to: https://github.com/minecraft-linux/mcpelauncher-manifest/wiki
GNU General Public License v3.0
312 stars 46 forks source link

Crash when attempting to start (Core dumped) #144

Closed ghost closed 7 years ago

ghost commented 7 years ago

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

loading native libraries
oslib: libGLESv2.so: -143143512
oslib: /home/kris27mc/Games/Minecraft/libs/native/libfmod.so.8.2: 135432288
loading hybris libraries
loading MCPE
loaded MCPE (at 4092362752)
apply patches
original: 85 83 87 86 131
post patch: 233 176 108 77 19
original: 85 83 87 86 131
post patch: 233 134 58 78 19
original: 85 83 87 86 129
post patch: 233 224 55 78 19
original: 83 87 86 131 236
post patch: 233 142 56 78 19
original: 83 131 236 8 232
post patch: 233 208 98 227 17
original: 83 87 86 131 236
post patch: 233 222 105 227 17
original: 85 83 87 86 131
post patch: 233 176 211 215 17
original: 83 87 86 131 236
post patch: 233 34 171 3 18
original: 83 131 236 8 232
post patch: 233 36 158 3 18
original: 83 131 236 8 232
post patch: 233 52 157 3 18
original: 83 86 131 236 20
post patch: 233 178 200 63 19
patches applied!
init app platform vtable
AppPlatform size = 141
init app platform
app platform initialized
init window
EGL_VERSION = 1.5 (DRI2)
create minecraft client
current storage path = data/current/
userdata path = data/user/
userdata path = data/user/
init minecraft client
userdata path = data/user/
userdata path = data/user/
fetch patch notes
get data url: assets/
internal storage path = data/private/
internal storage path = data/private/
userdata path = data/user/
userdata path = data/user/
get assert full path: uniforms.json
get data url: assets/

getjvmenv
getjvmenv
getjvmenv
getjvmenv
getjvmenv
getjvmenv
getjvmenv
getjvmenv
getjvmenv
getjvmenv
getjvmenv
getjvmenv
getjvmenv
getjvmenv
getjvmenv
getjvmenv
getjvmenv
getjvmenv
getjvmenv
getjvmenv
getjvmenv
getjvmenv
getjvmenv
getjvmenv
getjvmenv
getjvmenv
getjvmenv
getjvmenv
getjvmenv
getjvmenv
getjvmenv
getjvmenv
getjvmenv
getjvmenv
getjvmenv
getjvmenv
getjvmenv
getjvmenv
getjvmenv
getjvmenv
internal storage path = data/private/
creating fake store <MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqU9snkqLkTCYZQfQgNy9eabP/OcumQTgcoYhuBbmx2isicIX8mSUNJn64yxiA6acqnJzJxGbKW9H+gSWMuRtCtwI3Exb3sCq19EiVtjos4u5BJatzBKXXDDJeeYrejGk8FgT6ffokcilJFY4wgQQxDGFdfE/reAqm6+VKUtoqnjMpG0wVZn+o0bJfxNvE/ydJPlabDmoywEn9zEl0hXo0i+cimVlFZcTT6ed7U9celM2Ywg+7qVIu7fmBHPucTIoUAbipEAIvP2EntOqrhUG6GKJ219Qhdr43fvnyBailudNBiDRqA+x0rCH1JgmV/BvyAHTBylPzroeh9rWJNNPxQIDAQAB>
get product sku prefix: linuxget product sku prefix: linuxget product sku prefix: linuxget product sku prefix: linuxget product sku prefix: linuxget product sku prefix: linuxget product sku prefix: linuxget product sku prefix: linuxget product sku prefix: linuxget product sku prefix: linuxget product sku prefix: linuxget product sku prefix: linuxget product sku prefix: linuxget product sku prefix: linuxget product sku prefix: linuxget product sku prefix: linuxget product sku prefix: linuxget product sku prefix: linuxget product sku prefix: linuxget product sku prefix: linuxallows subscriptions: false
get product sku prefix: realmsallows subscriptions: false
get product sku prefix: realmsallows subscriptions: false
get product sku prefix: realmsallows subscriptions: false
get product sku prefix: realmsallows subscriptions: false
get product sku prefix: realmsallows subscriptions: false

restore from cache
register license change callback
userdata path = data/user/
get store id: LinuxStore
get sub platform store id: LinuxStore
getjvmenv
getjvmenv
xbox get app config singleton
xbox config: set sandbox (stub)
xbox get app config singleton
xbox config: set sandbox (stub)
Signal 11 received
Backtrace elements: 6
#0 ./mcpelauncher(_Z12handleSignaliPv+0x4b) [0x806b413]
#1 linux-gate.so.1(__kernel_sigreturn+0) [0xf7780c90]
#2 ./mcpelauncher() [0x805bfd3]
#3 ./mcpelauncher() [0x805c22b]
#4 HYBRIS FileInterface::fread(void*, unsigned int, unsigned int, void*) const+53 in libminecraftpe.so+0x1849d85 [0xf5711d85]
#5 /usr/lib32/libc.so.6(+0x1bd000) [0xf7383000]
Dumping stack...
#350 HYBRIS FileInterface::fopen(std::string const&, std::string const&) const+78 in libminecraftpe.so+0x1849bfe [0xf5711bfe]
#366 HYBRIS FileInterface::fread(void*, unsigned int, unsigned int, void*) const+53 in libminecraftpe.so+0x1849d85 [0xf5711d85]
#374 HYBRIS EncryptedFileInterface::fopen(std::string const&, std::string const&) const+369 in libminecraftpe.so+0x184a8c1 [0xf57128c1]
Signal 6 received
[1]    2452 abort (core dumped)  ./mcpelauncher
guppy42 commented 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

guppy42 commented 7 years ago

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

trollnuulnuul7 commented 7 years ago

@guppy42 Help me in #143

ghost commented 7 years ago

I'm closing this issue and adding a todo to the wiki.

phodopus42 commented 7 years ago

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.

ghost commented 7 years ago

@phodopus42 Would you mind using my repository as a playground to help fix this issue? My fork

MCMrARM commented 7 years ago

For whatever reason it tries to open "assets/assets/resource_packs/skins_premium/EverydayHeroes/content.zipe" (double assets/), I'll need to investigate.

MCMrARM commented 7 years ago

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.

MCMrARM commented 7 years ago

Workarounded.

phodopus42 commented 7 years ago

@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:

626 HYBRIS ZipFile::ZipFile(FileInterface const*, std::string const&, std::mutex&)+92 in libminecraftpe.so+0x17f547c [0xf5f0747c]

634 HYBRIS ZipPackAccessStrategy::getAsset(std::string const&, std::string&) const+145 in libminecraftpe.so+0x17f5a81 [0xf5f07a81]

640 HYBRIS AppPlatform::readAssetFile(std::string const&)+0 in libminecraftpe.so+0x179c700 [0xf5eae700]

646 HYBRIS AppPlatform::readAssetFile(std::string const&)+144 in libminecraftpe.so+0x179c790 [0xf5eae790]

648 HYBRIS operator delete(void*)+6 in libminecraftpe.so+0x2584266 [0xf6c96266]

655 HYBRIS AppPlatform::readAssetFile(std::string const&)+0 in libminecraftpe.so+0x179c700 [0xf5eae700]

658 HYBRIS DirectoryPackWithEncryptionAccessStrategy::getAsset(std::string const&, std::string&) const+176 in libminecraftpe.so+0x1ca9d80 [0xf63bbd80]

663 HYBRIS operator new(unsigned int)+12 in libminecraftpe.so+0x258652c [0xf6c9852c]

681 HYBRIS DirectoryPackWithEncryptionAccessStrategy::getAsset(std::string const&, std::string&) const+0 in libminecraftpe.so+0x1ca9cd0 [0xf63bbcd0]

682 HYBRIS SkinRepository::_loadPremiumSkinPack(PackManifest const&)+212 in libminecraftpe.so+0xff0ed4 [0xf5702ed4]

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.

ghost commented 7 years ago

@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

MCMrARM commented 7 years ago

@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.