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
