CoreELEC mediasrv unhandled exception after build 20260819

[ultraman]

At CoreELEC distro we changed linux kernel config to be more aligned with Android. And now after the changes mediasrv crashes:
https://gist.github.com/vpeter4/a186efc29879357da4dcd47cf76c74bc

and "mediaclient -e" command just freeze and doesn't show anything

kernel config changes:
https://github.com/CoreELEC/CoreELEC/commit/1b69c09a5f

According to AI it is glibc memory issue:

Given AArch64 calling convention (x0=arg1, x1=arg2, x2=arg3), this pattern — a dest/pointer arg of -1, a source of NULL, and a huge/wrapped length in x2 — is glibc memcpy/memmove/memset called with corrupted arguments. The -16 in x3 is also a classic glibc malloc chunk-header artifact (size field with flag bits). This smells like heap corruption or a bad size calculation inside mediasrv (buffer overflow, use-after-free, or an integer underflow producing SIZE_MAX-ish values)

Any idea how to proceed and get tuner working again?

[Sundtek]

Hi,

I do not recommend disabling `CONFIG_SYSVIPC`. Many Linux applications depend on System V IPC, and by disabling it you are stripping away a significant part of the standard Linux IPC functionality. Even embedded Linux set-top boxes commonly have `SYSVIPC` enabled. I would not remove it without a very good reason.

`CONFIG_SYSVIPC` provides System V shared memory, semaphores, and message queues. These interfaces have been part of Unix/Linux for decades and are still actively used. Shared memory in particular allows processes to exchange data efficiently without repeatedly copying large amounts of data between separate process buffers, which can save CPU time.

We also have an Android build of our driver that can operate without SYSVIPC, but Android uses different mechanisms for inter-process communication and shared memory. Alternatively, we can even use Unix domain sockets instead of SYSVIPC where necessary.

However, the fact that Android can work without System V IPC is not a good reason to remove it from a normal Linux build.

I see virtually no practical benefit in disabling `CONFIG_SYSVIPC`, while doing so unnecessarily reduces compatibility with existing Linux software.

If I would see the advantage of the removal I would have no problem with doing so - but limiting the system in that area doesn't look like a benefit to me.

[ultraman]

Sadly enabling CONFIG_SYSVIPC is not an option. As I wrote we aligned linux config to android one because we use one kernel module from Android (dovi.ko for DV playback) and seems it helps with stability. We didn't saw any other issues in last few days after this change. If anything else pop ups then we could (and should) reconsider but for now it will stay disabled.

This means tuner will just not work anymore with this option disabled?

[Sundtek]

There are many other changes, I highly doubt enabling sysvipc will affect your plan. Doublecheck this with your team, if it really breaks something we can help with enabling the socket route within the driver for your system.

Don’t limit your system for no real reason.

[ultraman]

As I wrote there is a reason for this changes. And we will not go back until really needed by some other components.

[Sundtek]

As mentioned first enable the feature again, I saw there were many changes not only sysvipc, sysvipc is very likely unrelated to what you really need or want. This won’t affect only us but also other software packages in a negative way. Android comes with its own software environment and they implemented another IPC mechanism.

By the way dream box also tried to disable sysvipc but they went back quickly years ago since they saw multiple drawbacks. Don’t force the removal of a standard unless it’s really officially deprecated and you really have to.

Please test re enabling it and loading the particular module which you are looking for

[ultraman]

Enabling CONFIG_SYSVIPC works. But the option will stay disabled. If we see issues later with other CE components we will need to find better solution.
But for now this is it.

I asked claude to make me LD_PRELOAD library. Seems it works.

Code: [Auswählen]

LD_PRELOAD library that emulates SysV IPC (shm/sem/msg) entirely in
userspace using POSIX shared memory objects + pthread PROCESS_SHARED
mutexes/condvars.  Intended for kernels built with CONFIG_SYSVIPC=n,
where shmget()/semget()/msgget() and friends would otherwise fail with
ENOSYS.


[Sundtek]

If you want to have an android system go fully android - a half hybrid doesn't make much sense; Enable SYSVIPC again it won't hurt it shouldn't interfere with your idea to load an existing other library.