Ubuntu have seen a number of SIGSEGV issues with plymouthd which are proving particularly hard to track down. Examples (note the number of duplicate bugs on each): https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/553745 (*) https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/849414 (*) - which spawned freedesktop bug 28548. Interestingly, some (like the 2 above) crash at the same part of the code, but others crash in bizarre locations. One explanation for this *might* be that alloca(3) -- called by ply_event_loop_process_pending_events() -- is failing. The problem with alloca is that it doesn't return a NULL if "allocation" (moving the stack pointer) fails. Quoting from the alloca(3) man page: There is no error indication if the stack frame cannot be extended. (However, after a failed allocation, the program is likely to receive a SIGSEGV signal if it attempts to access the unallocated space.) It's unproven, but this might well account for the strange behaviour. I've checked the way Ubuntu are building plymouth and calls to alloca(3) do indeed just tweak esp. The attached patch changes the events array to be statically allocated since: 1) That doesn't involve the use of the nefarious alloca(3). 2) The size of the array is always known, so there seems little advantage in allocating it dynamically each time this function is called (and it's called a lot :)
Created attachment 52088 [details] [review] patch to remove alloca(3) calls.
The stack shouldn't ever get too deep, so it's not likely to fail. If it is getting too deep, that stack size is running short that signals some bigger bug that's going to cause other problems. I have no problem getting rid of the alloca, though. Looking through the git log it used to just do a one time malloc which Charlie changed to alloca to silence valgrind or so. But we should try to find the root cause of your crashes. Under what circumstances do they happen?
i've commited your patch with one slight change (to make the buffer static) and more wordy commit message: http://cgit.freedesktop.org/plymouth/commit/?id=7e934255c502d7a5e75f7a5c86d904516abb13de
Thanks Ray. In answer to your question... Difficult to say - the crashes are being reported generally once the user has logged into their desktop session. Since we instruct plymouthd to quit when the display manager is starting that might point to a problem with the way memory is being freed up on exit. We've noticed a few places where fds are being leaked, but nothing significant enough to cause major crashes like this. I've been trying to pin the issue down using valgrind, but haven't come up with anything useful yet. So far, none of the users have been able to recreate the crash with plymouth debugging enabled, and although I've tried some pretty extensive stress tests using plymouth-x11 I am unable to recreate the crashes at all.
I'm going to close this out, since I believe you found your crasher in bug 28548
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.