Mac version sometimes fails to start about beebjit HOT 10 CLOSED

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?

from beebjit.

Thanks - I'm on macOS Big Sur.

from beebjit.

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

?

from beebjit.

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
`

from beebjit.

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.

from beebjit.

Archive.zip
Like this?

from beebjit.

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: f3160a3) 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.

from beebjit.

[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

from beebjit.

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

from beebjit.

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

from beebjit.