Enabling JIT crashes amiberry - rpi3A+

[giantclambake]

None too sure if this is expected behavior, but FTR ....

amiberry.rpi3jit.log.gz

HW: rpi3 model A+ OS: raspios_oldstable_full_arm64-2023-10-10/2023-05-03-raspios-bullseye-arm64-full.img.xz (CLI mode) Amiberry: amiberry-v5.6.1-rpi3-sdl2-64bit-rpios.zip binary release

To recreate: Start amiberry -> basic A1200 machine type -> CPU and FPU tab -> enable JIT -> Start emulation

Results in crash back to cmd prompt --- see resultant logfile.

TIA

[solskogen]

Can you try bookworm and compile amiberry and see it that also makes it crash?

[giantclambake]

Can you try bookworm and compile amiberry and see it that also makes it crash?

Will do ... I just discovered that the amiberry-v5.6.1-rpi3-sdl2-64bit-rpios.zip binary is broken under bookworm (just like with the x86-64 binary that I reported a while back...not compiled against libFLAC.so.12 which is part of bookworm), so I'll have to build it and report back....

...can someone fix that binary build issue please?.... =)

[giantclambake]

As requested;

OS: raspios_full_arm64-2023-10-10/2023-10-10-raspios-bookworm-arm64-full.img.xz HW: rpi3A+ Compiled amiberry-5.6.1 git clone / PLATFORM=rpi3-64-sdl2 (debug not enabled)

IRL... This just got really weird ; I'm running in console, just clicked start in amiberry...and nothing -- start button still 'depressed', I've lost mouse/gpm ...but I'm still ssh'd in, and the amiberry process has died...but I'm still seeing the GUI ...how odd =) Pity I hadn't turned logging on...

reboot

Start amiberry -> basic A1200 machine type -> CPU and FPU tab -> enable JIT -> Start emulation

result: crash ... see log.

Using the above configuration without JIT enabled boots the emulator to rom insert disk anim as it should.

Note: trying to enable RTG also results in a (different) crash, but I think JIT has to work first before considering that?

amiberry-rpi3-bookworm.log.gz

[solskogen]

Now that is strange. Could you try using PLATFORM=rpi3-64-dmx instead? Do a git clean -fdx first.

[giantclambake]

Now that is strange. Could you try using PLATFORM=rpi3-64-dmx instead? Do a git clean -fdx first.

Compile for hardware I don't use? Sure....I'll do that .... you're suspicious that it's something in SDL?

On that point, I just retried with that same build but with 'use_sdl2_render_thread=yes' set in amiberry.conf ~ it still crashes but the trace is a little different.... logfile attached.

amiberry-sdlrender=y.log.gz

[giantclambake]

As requested;

OS: raspios_full_arm64-2023-10-10/2023-10-10-raspios-bookworm-arm64-full.img.xz HW: rpi3A+ Compiled amiberry-5.6.1 git clone / PLATFORM=rpi3-64-dmx (debug not enabled)

M'kay...this turned into a shambles, and more an examination of why the rpi3-64-dmx target cannot get to GUI, in neither console nor X .... note: for sake of clarity, the rpi3-64-sdl2 binary is named 'amiberry' ; the rpi3-64-dmx binary is named 'amiberrydmx'

Try 1 --> launch amiberrydmx from cmdline in console --> I'm left with a blinking cursor and no amiberry GUI ... awesome start, ssh shell, process is running but idle, killall -9 amiberrydmx, and although console returns to cmdline prompt, KBD input is null ...sigh, great... so the rpi3-64-dmx target cant do GUI and breaks console keyboard input in the process...time for plan B ...

reboot

Try 2 --> from console, startx ....let's see what's going on there...open xterm, launch amiberry (sdl2), working as expected.

Now launch amiberrydmx ....

amiberry-rpi3-64-dmx-X.log.gz

Okay...that's broken =) Seems xinput is lost as well -> ssh shell, again process is active but idle, kill amiberry, xterm releases properly and I've got xinput back.... so it's just the GUI? ....comparative runs ;

./amiberry -f conf/default1200.uae -G

result: works as expected, boot emulation to rom insert disk anim

amiberry-rpi3-64-sdl2-1200-G-X.log.gz

./amiberrydmx -f conf/default1200.uae -G

result: doesn't spawn emulation window, and again appears active but idle using top in ssh shell, kill process...

amiberry-rpi3-64-dmx-1200-G-X.log.gz

OK...so we can actually start the emulation ...ergo.... logout -> exit to commandline...

All things being equal, if I feed it an A1200.uae conf file with JIT enabled, even without GUI we should either hit, or not, the same crash with JIT enabled....

./amiberrydmx -f conf/default1200jit.uae -G

result: we hit the same crash =)

amiberry-rpi3-64-dmx-1200jit-G.log.gz

For sake of completeness, config files attached;

default1200.uae.gz default1200jit.uae.gz

[solskogen]

I don't have a Pi3 here, but I've compiled a Rpi3 version (PLATFORM=rpi3-64-sdl2) on my Rpi400 running bookworm both in X and KMS/DRM/console. And used you configuration. No problem what-so-ever. That in mind, I don't have access to the same kickstart as you. I even tried setting my Pi400 to only have access to the same amount of memory as you, but still no crash. This probably requires somebody with access to a rpi3.

[giantclambake]

Yeah, I don't see this behavior on my rpi4 nor my x86-64 builds, so it seems to be something specific to rpi3 ; thanks for the ideas & testing though ~ it is appreciated =)

[reedlove]

I was able to compile today's source code and run Amiberry on my RPI3B+ using KMS/DRM/console on 2023-10-10-raspios-bookworm-arm64-lite.img A1200 with 8MB fast ram, Amiga OS 3.2.2.1 and kickstart A1200.47.111.rom

[solskogen]

But does it work when JIT is enabled? :)

[reedlove]

But does it work when JIT is enabled? :)

Yup! =]

[solskogen]

Could you post your config, so that @giantclambake can test it?

[giantclambake]

I'd be interested in trying it, however, this evening I discovered that GUI -> Quickstart -> Model A4000 (basic) --> Start also results in a crash (JIT not enabled), which is odd (both 3.0 & 3.1 kickstarts). The only tacit difference between rpi3 models here, would be the amount of system ram?

Using the base A1200 model from Quickstart, no JIT, boot to insert disk anim, in top sees ;

   PID USER   PR  NI    VIRT    RES    SHR    S  %CPU  %MEM                         
   1421 gcb    20   0  736692 155432  60592   R  77.2  36.3

[reedlove]

Could you post your config, so that @giantclambake can test it?

Are you referring to my build of it?

[solskogen]

Ah, you tried with 3B+, not 3A+. We would need a 3A+ to double check.

[giantclambake]

Just a 'to be expected' bump ~ not surprisingly, still crashes in amiberry-v5.6.2-debian-bookworm-aarch64-rpi3.zip

[midwan]

The log mentions: Memory address is higher than 32 bit. JIT will crash

I think this is related to the platform or distro perhaps, but I'm not sure. Hard to say without being able to recreate it elsewhere... :)

[giantclambake]

Yes I noticed that ~ it stands in some contraction to the message emitted at crash of 'Error not in JIT code' just before sig_11 ...ie; does this infer JIT didn't crash, or, was JIT not even (attempted) to be used, and this message also appears in that case?

You'd think it may be distro related, but we have the test case of running the same debian bookworm image on both rpi3A+ & rpi3B+ and in the former case you get the crash, but not in the latter. (this doesn't exclude the case of the distro itself changing things somewhere, based on the rpi3 model it's installed to...difficult without the same hardware onhand)

Anyhoo.... I was looking at BlitterStudio/amiberry-lite#5 and read the commit wrt the jit-test branch ~ I figured it was worth a poke.

--- clone [test-jit-crash], compile PLATFORM=rpi3-64-sdl2 with debug enabled, launch amiberry with the cmdline;

strace -o output.log ./amiberry-jitdbg -f conf/default1200jit.uae -G

The entire output.log is quite big, so I've just attached the stack trace stanza incase it pops a clue =)

What's throwing the message "Error: Invalid argument.\n" just before the segfault?

output-crash.log.gz

[solskogen]

Does it crash now, with the latest fixes in master?

[giantclambake]

Yep, afraid so ;(

No longer see the memory address error, but it still crashes ~ same config.uae with JIT disabled works fine.

amiberry.log.gz