Sam Bushell

We will attempt to reproduce on 1.20.72.

There is no ad blocker involved.

If you strafe right at full speed and then hold down with a finger from the other hand to break blocks as you move:

• on 1.19.73, every block you pass will break

• on 1.19.80 and 1.19.81, every other block you pass will break
  So it seems like the block breaking rate in creative has been halved.

We're also seeing this.
The bug reproduces on 1.19.81 and 1.19.80 but not in 1.19.73 – all on iPadOS.

This is a crash when signing in — the user hasn’t gotten a chance to start playing yet.

On our devices the issue also resolved itself, apparently due to retrying with different network conditions: in two cases, on a WiFi network away from home; in others, after restarting local network routers. 

We are seeing this on iPad (5th Generation), iPhone Xr, iPad Pro 10.5, iPad Air 2.

It happened twice in a row, and then we didn't see it any more after that that day.  I've attached the other crash log.  The crashes do look identical: same offset off NULL, same thread name MC_SERVER, same backtrace in the crashing thread.

I speculated that it might be to do with upgrading the world to a new version, but I don't have any real data about that.  

We have been reluctant to enter another world that we care about our inventory in, so we have not tried a ton since that time.

With all due respect, this is NOT an enhancement request or "suggestion". Previous versions of Minecraft PE were functional on iPad mini 1 (and other 512MB iPads). The recent and current versions are simply not usable on this hardware because of the immediate jetsams. Customers who purchased this app when it worked, now find that it does not work. It is very important that you prioritise fixing this. For those customers with 512MB iPads, this issue is more important than any new features, because it prevents them from enjoying the game at all.

It's also inaccurate to consider it a duplicate of MCPE-19439. Besides the obvious process flaw of marking a report of a bug that's still happening as a duplicate of a bug report that was determined to be resolved, there has also been change between the circumstances of MCPE-19439. The previous report was against 1.0.0; this bug report is filed against 1.2.3. Between these versions, there were numerous versions of MCPE which were usable.

I can speak with some authority that this is not a dup of MCPE-17695. It can't make sense for a NULL dereference crash to be the same immediate cause as a foreground jetsam event. A foreground jetsam event means that iOS determined that it was in a critical page shortage, so bad that it had to terminate the frontmost app. A NULL dereference is a seg fault.

For this bug report, the correct next steps are to symbolicate the crash log with Xcode and the dSYM from when 0.16.0.5 was built, and examine the code to try to reconstruct why it was dereferencing a NULL pointer at that crash point.

Ah, MCPE-17695 is the dup target, I see it now.

As in MCPE-17781: the JetsamEvent-[date].ips files suggest that minecraftpe has increased its memory usage in 0.16.0 beyond what is sustainable on 512GB iOS devices.

As in MCPE-17781: the JetsamEvent-[date].ips files suggest that minecraftpe has increased its memory usage in 0.16.0 beyond what is sustainable on 512GB iOS devices.

My kids are also singularly unimpressed by Minecraft PE 0.16.0 exiting as soon as they load any world on their iPad mini 1st Gen. These and the iPod Touch 5th Gen are all A5 based iOS devices with 512GB RAM.

You can see by reading the JetsamEvent-[date].ips files generated when Minecraft exits that minecraftpe is being terminated because of "reason" : "vm-pageshortage" while "largestProcess" : "minecraftpe". It generally has on the order of 230MB of dirty memory: "rpages" : 57612 * "pageSize" : 4096.

So, the problem appears to be that minecraftpe has increased its memory usage in 0.16.0 beyond what is sustainable on 512GB iOS devices.

Existing worlds. Probably from 0.11.0 or earlier.

Hmm, maybe it's not bonjour? I ran a bonjour browser and didn't find a service that corresponded to the multiplayer games that were being shared.

Further exploration: resuming the game, on the secondary iPad I forced the player to re spawn by destroying any recent bed and digging through the bottom, through bedrock, and falling through. The respawn point was indeed near where that player's compass said it would be.

Then I took off flying more or less at random and happened to find the way back to the other player. What I found then was that even when the two players were near each other, the compasses still disagreed about where they should point to. The primary iPad's player's compass pointed to a point nearby that could be walked around; the secondary iPad's player's compass stayed pointing in a consistent direction (consistent with pointing to that same far-away place).

The idea that there is a distance threshold after which this problem starts happening is interesting.
Is there a way to view player coordinates in MCPE on iOS?