Illegal instruction crash vlc 3.0.12 on Raspberry pi Zero W

[dhdurgee]

It appears the binaries you are creating are not compatible with the Raspberry Pi Zero W as they contain neon instructions. Please see forum thread here for details:

https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=307312

[dhdurgee]

VLC support had me run it under gdb yielding:

code bt
#0 0xa22e9004 in ?? () from /usr/lib/arm-linux-gnueabihf/vlc/plugins/mmal/libmmal_codec_plugin.so
#1 0xa22d9314 in ?? () from /usr/lib/arm-linux-gnueabihf/vlc/plugins/mmal/libmmal_codec_plugin.so
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)[/code]

and

[code] ┌────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐

│0xa22e9004 vdup.8 d7, r2 │
│0xa22e9008 subs r3, r3, #8 │
│0xa22e900c vmov.i8 d6, #255 ; 0xff │
│0xa22e9010 blt 0xa22e9098 │
│0xa22e9014 cmp r3, #8 │
│0xa22e9018 mov r4, r3 │
│0xa22e901c ble 0xa22e9034 │
│0xa22e9020 rsb r3, r0, #0 │
│0xa22e9024 ; instruction: 0xe7e23153 │
│0xa22e9028 cmp r3, #0 │
│0xa22e902c blne 0xa22e90a4 │
│0xa22e9030 sub r3, r4, r3 │
│0xa22e9034 vld4.8 {d16-d19}, [r1] │
│0xa22e9038 vmull.u8 q15, d19, d7 │
│0xa22e903c vld4.8 {d20-d23}, [r0] │
│0xa22e9040 vsra.u16 q15, q15, #8 │
│0xa22e9044 subs r3, r3, #8 │
│0xa22e9048 vrshrn.i16 d31, q15, #8 │
│0xa22e904c vsub.i8 d30, d6, d31 │
│0xa22e9050 vmull.u8 q12, d16, d31 │
│0xa22e9054 vmull.u8 q13, d17, d31 │
│0xa22e9058 vmull.u8 q14, d18, d31 │
│0xa22e905c addge r1, r1, #32 │
└────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
multi-thre Thread 0xa1e0e3e0 ( In: L?? PC: 0xa22e9004
(gdb) [/code]

The vlc debug log shows:

Code: Select all
[code]
[9bbdadd0] main blend debug: looking for video blending module matching "any": 3 candidates
[9bbdadd0] mmal_codec blend debug: OpenBlendNeon: (blend) RGBA/RGBA,273x15 [(0,0) 273x15]->RV32/RGBA,288x192 [(0,0) 288x192]
[9bbdadd0] main blend debug: using video blending module "mmal_codec"
[/code]

[6by9]

@jc-kynesim Looks to be one for you.

[dhdurgee]

True. I decided to post here as well after I realized that vlc is likely not the only place that neon instructions would show up and crash something else on the Pi Zero and others with this CPU. My nightmare would be if they are hiding somewhere in the kernel waiting to trigger a panic.

[jc-kynesim]

Kernel issues are unlikely - that is built per platform for the exact processor in use - we (afaik) ship a single VLC image for all platforms.

I guess this case is fixable with run time capability testing but it does have the caveat that anything that is using the non-neon path is going to be very slow (on what is almost certainly a slow processor to start with).

[XECDesign]

@jc-kynesim Is there a configuration in your current patch for armv6 acceleration support, or is this unsupported? Not sure if this is a packaging issue on my end or just an unsupported use case.

In the past, I got around the issue with this patch https://github.com/RPi-Distro/vlc/blob/buster-rpt/debian/patches/armv6.patch but I guess it doesn't work anymore?

[XECDesign]

Ah, looks like there's now an OpenBlendNeon function, but that check is only in OpenBlendMmal. Should be fixable on my end.

[jc-kynesim]

Good oh! And thanks for that - I'll admit I wasn't really thinking that anyone would try and use a non-neon Pi for any video that required actually touching the pixels (or if I'm being really honest - any video at all).

[dhdurgee]

I am glad to hear this is fixable. Could you let me know when I can update my unit with the fixed binary from the repository?

Is there a possibility that there are other common binaries out there that also include neon instructions that could crash on those systems with the same CPU as mine? I would think now would be the time to look for this.

Note that cdg karaoke is low resolution, low frame rate video and works even on my Pi Zero W without problems.

[dhdurgee]

In case you are interested the data stream for CDG video is at 28,800bps and consists of 300x216 frames of 4 bit color.

[XECDesign]

If you add 'untested' after 'main' in /etc/apt/sources.list.d/raspi.list and update, you should get a patched version.

I wasn't able to test it myself since I couldn't reproduce the issue with the previous build when I briefly tried yesterday.

[dhdurgee]

I have added the untested option and updated to your new build. It appears to be working properly as expected with karaoke tracks.

I am now trying to address the problem with window size and position. Given the small size of the CDG image I want to enlarge it. I can use a --zoom 2 successfully, but a --zoom 4 runs off the screen as the window position places the upper left corner in the same place the window without a zoom is placed. As you might expect full screen or non binary zoom factors are out of the question without the neon instructions.

Thank you for your assistance in this matter.

[jc-kynesim]

I assume you are using the mmal_vout device rather than X? If so then all scaling will be done in h/w and should have no impact. Having said that I will add the caveat that if you try to add filters then you will have a s/w path that will just stall prior to display.

[jc-kynesim]

... having said that given that you are coming from a format that the h/w doesn't support natively (or at least I don't think it does) it is possible that vlc will "helpfully" try to scale it before display. What does happen if you add the --fullscreen flag?

[XECDesign]

I've moved it from untested to main. You should remove untested now, since you may end up with some packages which aren't ready for general use.

[dhdurgee]

Karaoke.zip
I am operating the Rpi0W via ssh from my laptop and typically have only the HDMI and power connected to it. The HDMI output goes to my entertainment center where it is one of three HDMI inputs.

My usual way to call vlc is:

DISPLAY=:0 vlc -I cli -V x11 [media to be played]

In that case of a karaoke track this would be the mp3 file of the pair. As noted above this results in a small video window centered over the desktop. I can add --zoom 2 or --zoom 3 before the -I cli to enlarge this, but it does result in lost frames. I attempted to get an idea of this by the stats command near the end of a track and found the following:

no zoom - 8900 displayed, 250 list
2x zoom - 1337 displayed, 7824 lost
3x zoom - 662 displayed, 8480 lost

The losses, especially at 2x, are not very apparent, as the frames don't change much in general

I have hopefully attached a zip with the track that lead me to discover the problem, in case you would like to do your own testing.

Thank you again for your help with this problem.

[jc-kynesim]

Ah, looks like there's now an OpenBlendNeon function, but that check is only in OpenBlendMmal. Should be fixable on my end.

@XECDesign I'm finally getting round to fixing up these issues at my end. Any clue why your patch disables OpenBlendMmal? the only couple of bits of neon are blend & piccpy. Piccpy already has an "if neon" in the only place it is used and blend is only used by BlendNeon.

[XECDesign]

It may be there either by mistake or because it was needed at some point. If it has been tested and works without the check in OpenBlendMmal, I can remove it.

[jc-kynesim]

I don't actually have a Pi1/0 here to check against