08.01.2022 21:13, Eric W. Biederman пишет: > Dmitry Osipenko <digetx@xxxxxxxxx> writes: > >> 05.01.2022 22:58, Eric W. Biederman пишет: >>> >>> I have not yet been able to figure out how to run gst-pluggin-scanner in >>> a way that triggers this yet. In truth I can't figure out how to >>> run gst-pluggin-scanner in a useful way. >>> >>> I am going to set up some unit tests and see if I can reproduce your >>> hang another way, but if you could give me some more information on what >>> you are doing to trigger this I would appreciate it. >> >> Thanks, Eric. The distro is Arch Linux, but it's a development >> environment where I'm running latest GStreamer from git master. I'll try >> to figure out the reproduction steps and get back to you. > > Thank you. > > Until I can figure out why this is causing problems I have dropped the > following two patches from my queue: > signal: Make SIGKILL during coredumps an explicit special case > signal: Drop signals received after a fatal signal has been processed > > I have replaced them with the following two patches that just do what > is needed for the rest of the code in the series: > signal: Have prepare_signal detect coredumps using > signal: Make coredump handling explicit in complete_signal > > Perversely my failure to change the SIGKILL handling when coredumps are > happening proves to me that I need to change the SIGKILL handling when > coredumps are happening to make the code more maintainable. Eric, thank you again. I started to look at the reproduction steps and haven't completed it yet. Turned out the problem affects only older NVIDIA Tegra2 Cortex-A9 CPU that lacks support of ARM NEON instructions set, hence the problem isn't visible on x86 and other CPUs out of the box. I'll need to check whether the problem could be simulated on all arches or maybe it's specific to VFP exception handling of ARM32.
