search

scarybeasts / beebjit

A very fast BBC Micro emulator.
Other
132 stars 15 forks source link

Mac version sometimes fails to start #39

Closed TobyLobster closed 2 years ago

TobyLobster commented 2 years ago

Sometimes beebjit (Mac tagged version v0.9.7) fails to start, but trying again often works. Here is the output where I tried to run it once and it failed, but trying again then worked:

% ./beebjit -0 test/games/Disc108-FroggerRSCB.ssd
BAILING: mmap in wrong location (expected 0x1f000000, got 0x20000000), heap 0x511a30 binary 0x407880
% ./beebjit -0 test/games/Disc108-FroggerRSCB.ssd
info:audio:sub-period size 86 time 1791us
unimplemented:misc:write of TUBE region
scarybeasts commented 2 years ago

Thanks for the report. It should be possible to tweak a few constants to get this to work... hopefully!

Out of curiosity, what version of macOS is this?

TobyLobster commented 2 years ago

Thanks - I'm on macOS Big Sur.

scarybeasts commented 2 years ago

Does it work reliably if you edit asm/asm_platform.h and change:

define K_BBC_MEM_RAW_ADDR 0x1f008000

to

define K_BBC_MEM_RAW_ADDR 0x27008000

?

TobyLobster commented 2 years ago

Does it work reliably if you edit asm/asm_platform.h and change:

define K_BBC_MEM_RAW_ADDR 0x1f008000

to

define K_BBC_MEM_RAW_ADDR 0x27008000

?

Sadly not: `% ./beebjit -0 test/games/Disc108-FroggerRSCB.ssd BAILING: mmap in wrong location (expected 0x30000000, got 0x38000000), heap 0x6072b0 binary 0x407880

% ./beebjit -0 test/games/Disc108-FroggerRSCB.ssd BAILING: mmap in wrong location (expected 0x30000000, got 0x40008000), heap 0x604b50 binary 0x407880

% ./beebjit -0 test/games/Disc108-FroggerRSCB.ssd BAILING: mmap in wrong location (expected 0x27000000, got 0x28000000), heap 0x14063c0 binary 0x407880 `

scarybeasts commented 2 years ago

Interesting! It's hard to know what to make of those. It looks like this older version of macOS could be ignoring the requested address, even though there's likely nothing there already.

We could confirm by grabbing a vmmap output (or two!) for the beebjit process at the time of the BAILING message. One way to do this would be to modify util_bail() in util.c to add "while (1) {}" after the fprintf. This would force an infinite loop at the time of the BAILING, enabling vmmap to be used on the beebjit process.

TobyLobster commented 2 years ago

Archive.zip Like this?

scarybeasts commented 2 years ago

Thanks, that's perfect. It looks like this older version of macOS likes to reserve huge malloc areas, and these are conflicting with beebjit's attempts to reserve address space for various things.

Can you try the latest code on master (as of commit: https://github.com/scarybeasts/beebjit/commit/f3160a3b5a48ae254fb8e4adcb0d8d214457ef33) and see if it works now? It's an attempt at fixing this in a simple manner, which might not be perfect, but might do the trick. It squishes beebjit's mappings together so that the huge malloc areas will be placed elsewhere.

scarybeasts commented 2 years ago

[For posterity, here's the older version of macOS grabbing 0x30000000 before beebjit can get it!!]

mapped file 2a008000-2a010000 [ 32K 0K 0K 0K] rw-/rwx SM=S/A /private/tmp/beebjit6q9lU1 mapped file 2b008000-2b010000 [ 32K 0K 0K 0K] rw-/rwx SM=S/A /private/tmp/beebjit6q9lU1 VM_ALLOCATE (reserved) 2b010000-2b018000 [ 32K 0K 0K 0K] rw-/rwx SM=NUL reserved VM address space (unallocated) MALLOC_MEDIUM 30000000-30800000 [ 8192K 1624K 1624K 0K] rw-/rwx SM=PRV DefaultMallocZone_0x4cf000 MALLOC_MEDIUM (reserved) 30800000-38000000 [120.0M 0K 0K 0K] rw-/rwx SM=NUL DefaultMallocZone_0x4cf000

TobyLobster commented 2 years ago

That is working nicely - thank you, thank you! I've tried launching 15 times and it succeeded each time.

scarybeasts commented 2 years ago

Great. Thanks for helping sort out the teething troubles with the new macOS port!