Bus error at moments of video playback

[hissingshark]

Game or games this happens in

M.A.C.H. Modified Air Combat Heroes, Tekken 6. Basically anything with a video segment.

What area of the game / PPSSPP

Whenever there is video playback PPSSPP crashes with a Bus error.
Most games have a video intro so cannot be played from the beginning. Playing from a savestate is a workaround, until a video is encountered again...

What should happen

It shouldn't crash.

Logs

I assumed an ffmpeg/libavcodec issue.
I ran though gdb and got:

Thread 20 "Emu" received signal SIGBUS, Bus error.
[Switching to Thread 0xee32a440 (LWP 2968)]
0xab206cce in ff_h264_idct_dc_add_neon () at libavcodec/arm/h264idct_neon.S:76
76 mov r3, #0

Backtrace gave:

#0 0xab206cce in ff_h264_idct_dc_add_neon () at libavcodec/arm/h264idct_neon.S:76
#1 0xab206e00 in ff_h264_idct_add8_neon () at libavcodec/arm/h264idct_neon.S:172
#2 0xab105796 in hl_decode_mb_simple_8 (h=0xe0800030, sl=) at libavcodec/h264_mb_template.c:243
#3 0xab108a46 in ff_h264_hl_decode_mb (h=h@entry=0xe0800030, sl=sl@entry=0xdee78020) at libavcodec/h264_mb.c:835
#4 0xab1147c0 in decode_slice (avctx=avctx@entry=0xe62ee5d0, arg=0xdee78020) at libavcodec/h264_slice.c:2387
#5 0xab1182ee in ff_h264_execute_decode_slices (h=h@entry=0xe0800030, context_count=context_count@entry=1) at libavcodec/h264_slice.c:2556
#6 0xab0ef870 in decode_nal_units (h=h@entry=0xe0800030, buf=buf@entry=0xeda07da0 "", buf_size=buf_size@entry=402, parse_extradata=parse_extradata@entry=0)
at libavcodec/h264.c:1648
#7 0xab0f0e96 in h264_decode_frame (avctx=0xe62ee5d0, data=0xe62f6120, got_frame=0xee329a74, avpkt=) at libavcodec/h264.c:1874
#8 0xab1f0fdc in avcodec_decode_video2 (avctx=0xe62ee5d0, picture=0xe62f6120, got_picture_ptr=0xee329a74, avpkt=0xee329a78) at libavcodec/utils.c:2128
#9 0xaaca45fa in MediaEngine::stepVideo(int, bool) ()
#10 0xaac63310 in void WrapU_UUUUU<&(sceMpegAvcDecode(unsigned int, unsigned int, unsigned int, unsigned int, unsigned int))>() ()
#11 0xaabf99fc in CallSyscallWithoutFlags(HLEFunction const*) ()
#12 0xe8c69a40 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

So it looks like that may be the case.

Platform

Linux / BSD

Mobile phone model or graphics card

Vero4K - Amlogic S905x - Mali 450 GPU.

PPSSPP version affected

Built from 1.14.4 and been building back as far as 1.13.2

Last working version

Sorry, tried to bisect but not found a working version again.

Graphics backend (3D API)

OpenGL / GLES

Checklist

• Test in the latest git build in case it's already fixed.
• Search for other reports of the same issue.
• Try resetting settings or older versions and include if the issue is related.
• Try without any cheats and without loading any save states.
• Include logs or screenshots of issue.

[LunaMoo]

We're you using PPSSPP FFMPEG or system one? The latter is probably broken and it's heavily discouraged to use it, but still commonly used by Linux users regardless of warnings.

[hrydgard]

Apart from the issue of PPSSPP's vs system FFMPEG, since this stuff is working on a ton of other Linux/ARM platforms, I'd say this is likely to be some kind of platform bug, maybe something gets the stack misaligned, but that shouldn't matter:

From the callstack, it looks like it faults in some assembler code that uses NEON SIMD instructions. What's confusing to me here is that NEON is generally very lax about alignment, it never crashes, just gets slower, so why you'd get a bus error there I don't understand.

[hissingshark]

We build an armv7 version of the PPSSPP FFMPEG.

That I can't seem to bisect it does raise the possibility of an environment issue. Perhaps I shall have to try reinstalling my system from old images until it works. Although I'm not sure a success there would aid an actual fix.

[hrydgard]

You could try building without the NEON stuff and see if that helps, usually it's fast enough..

[hissingshark]

Configured your FFMPEG with --disable-neon when building. Runs fine now. Thank you.

[unknownbrackets]

https://community.arm.com/support-forums/f/architectures-and-processors-forum/6133/how-to-avoid-bus-error-while-using-neon-instruction-vld2-32-on-cortex-a7/20220

NEON does support instructions that indicate the address is aligned, so I guess it somehow wasn't in this case. Not sure why.

-[Unknown]

[hrydgard]

Oh right, those are gone in arm64 though which might be what I was thinking about..