Closed umxprime closed 1 year ago
The exception appears to happen in this line (since it matches the exception subcode and it is the only occurrence in FFmpeg): https://github.com/FFmpeg/FFmpeg/blob/master/libswresample/aarch64/audio_convert_neon.S#L87
I have no idea why the Apple silicon doesn't like that instruction. It had to execute the same instruction with other register numbers to get to that line. Maybe this exception is generated also when trying to convert NaN or infinity to an integer? What is the contents of the v16 register in that thread after it crashed?
For this instruction I have
(lldb) p $v16
(unsigned char __attribute__((ext_vector_type(16)))) $0 = (0x95, 0x79, 0x81, 0x3f, 0x82, 0xc7, 0x71, 0x3f, 0xac, 0xc0, 0x54, 0x3f, 0xb3, 0x87, 0x3b, 0x3f)
Got another one given I let the preview plays in song section screen
Process 26491 stopped
* thread #8, name = 'AudioQueue thread', stop reason = EXC_BAD_INSTRUCTION (code=1, subcode=0x4f21fc67)
frame #0: 0x0000000100ab1208 libswresample.4.dylib`___lldb_unnamed_symbol78 + 144
libswresample.4.dylib`___lldb_unnamed_symbol78:
-> 0x100ab1208 <+144>: fcvtzs.4s v7, v3, #0x1f
0x100ab120c <+148>: st1.4s { v23 }, [x0], #16
0x100ab1210 <+152>: b.ne 0x100ab11ac ; <+52>
0x100ab1214 <+156>: ands x2, x2, #0xf
Target 0: (ultrastardx) stopped.
(lldb) p $v3
(unsigned char __attribute__((ext_vector_type(16)))) $2 = (0x21, 0xe6, 0x70, 0x3f, 0xcf, 0x53, 0x7d, 0x3f, 0x7f, 0x87, 0x83, 0x3f, 0xd9, 0xfa, 0x7d, 0x3f)
On an i.MX8M the fcvtzs instruction converts 0x95, 0x79, 0x81, 0x3f, 0x82, 0xc7, 0x71, 0x3f, 0xac, 0xc0, 0x54, 0x3f, 0xb3, 0x87, 0x3b, 0x3f
to 0xFF 0xFF 0xFF 0x7F 0x00 0xC1 0xE3 0x78 0x00 0x56 0x60 0x6A 0x80 0xD9 0xC3 0x5D
and 0x21, 0xe6, 0x70, 0x3f, 0xcf, 0x53, 0x7d, 0x3f, 0x7f, 0x87, 0x83, 0x3f, 0xd9, 0xfa, 0x7d, 0x3f
to 0x80 0x10 0x73 0x78 0x80 0xE7 0xA9 0x7E 0xFF 0xFF 0xFF 0x7F 0x80 0x6C 0xFD 0x7E
. So in both cases there was a floating point number > 1 that had to be clipped to 0x7FFFFFFF.
Here the Free Pascal runtime enables floating point exceptions. The i.MX8M does not support these exceptions. This page confirms that macOS delivers floating point exceptions with SIGILL instead of with SIGFPE. We could try to use the SetExceptionMask function to disable the exceptions, but I don't know if the mask is inherited to new threads.
IIRC FPE works per thread and I remember that I had to handle such case given I had to do some signal processing with intel primitives or Apple Accelerate framework
We don't create that thread. I'm unsure if we should change the exception mask permanently or revert it every time we return from the audio callback...
@umxprime, please try https://github.com/s09bQ5/USDX/tree/fpu-exceptions
So far so good with your patch 😍
Actual behaviour
Given I start playing a song the app quits unexpectedly.
Expected behaviour
Song playback shouldn't crash app .
Steps to reproduce
Details
Provide some additional information:
Here's the responsible thread's backtrace
And here is the full backtrace