Created attachment 117613 [details] [review]
boot-splash: don't crash in free if module not loaded

ply_boot_splash_free currently calls some code that depends
on a module being loaded.  We call ply_boot_splash_free to
clean up the boot splash object if a module can't be loaded,
leading to crash.

This commit addresses that issue by only calling the module
specific destruction code in ply_boot_splash_free in the case
where a module is loaded.

So I pushed this, but there's more to the story. If you're seeing
this crash, then you can't load the built in plugin.  That should
never fail since it's ... built in.  Maybe somehow plymouthd isn't
getting built -rdynamic ?

Attachment 117613 [details] pushed as f806843 - boot-splash: don't crash in free if module not loaded

(In reply to Ray Strode [halfline] from comment #2)
> So I pushed this, but there's more to the story. If you're seeing
> this crash, then you can't load the built in plugin.  That should
> never fail since it's ... built in.  Maybe somehow plymouthd isn't
> getting built -rdynamic ?
> 
> Attachment 117613 [details] pushed as f806843 - boot-splash: don't crash in
> free if module not loaded

Thanks for quick fix, it improved situation that atleast now it doesn't crash, only it shows this http://i.imgur.com/GRkzyak.jpg splash instead of my image. Now same on shutdown too, previously sometimes on shutdown it would show my image.

I'm compiling with GCC 5.2.0 and

CPPFLAGS="-D_FORTIFY_SOURCE=2"
CFLAGS=-march="native -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4 -g -fvar-tracking-assignments -Wall -Wstrict-aliasing=2"
CXXFLAGS="-march=native -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4 -g -fvar-tracking-assignments -Wall -Wstrict-aliasing=2"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro"


./autogen.sh \
    --prefix=/usr \
    --exec-prefix=/usr \
    --sysconfdir=/etc \
    --localstatedir=/var \
    --libdir=/usr/lib \
    --libexecdir=/usr/lib \
    --sbindir=/usr/bin \
    --enable-systemd-integration \
    --enable-drm \
    --enable-tracing \
    --enable-pango \
    --enable-gtk=no \
    --with-release-file=/etc/os-release \
    --with-logo=/usr/share/plymouth/arch-logo.png \
    --with-background-color=0x000000 \
    --with-background-start-color-stop=0x000000 \
    --with-background-end-color-stop=0x4D4D4D \
    --without-rhgb-compat-link \
    --without-system-root-install

make


I tried without any optimizations and even explicitly adding -rdynamic to CFLAGS/CXXFLAGS but that didn't change anything.
Maybe in initramfs I don't have something needed?
Here's a file list of what I've there https://paste.kde.org/p8r6mi0cs

/etc/plymouth/plymouthd.conf contains
[Daemon]
Theme=arch-glow
ShowDelay=9


and see /var/log/plymouth-debug.log at https://paste.kde.org/pquejnnsr


journal

plymouthd[110]: [main.c:1891]                               check_verbosity:redirecting debug output to /dev/tty1
plymouth[114]: [ply-event-loop.c:759]               ply_event_loop_stop_watching_fd:stopping watching fd 6
plymouth[114]: [ply-event-loop.c:775]               ply_event_loop_stop_watching_fd:removing destination for fd 6
plymouth[114]: [ply-event-loop.c:759]               ply_event_loop_stop_watching_fd:stopping watching fd 6
plymouth[114]: [ply-event-loop.c:775]               ply_event_loop_stop_watching_fd:removing destination for fd 6
plymouth[114]: [./ply-boot-client.c:795]        ply_boot_client_detach_from_event_loop:detaching from event loop
plymouth[674]: [ply-event-loop.c:759]               ply_event_loop_stop_watching_fd:stopping watching fd 6
plymouth[674]: [ply-event-loop.c:775]               ply_event_loop_stop_watching_fd:removing destination for fd 6
plymouth[674]: [ply-event-loop.c:759]               ply_event_loop_stop_watching_fd:stopping watching fd 6
plymouth[674]: [ply-event-loop.c:775]               ply_event_loop_stop_watching_fd:removing destination for fd 6
plymouth[674]: [./ply-boot-client.c:795]        ply_boot_client_detach_from_event_loop:detaching from event loop
plymouth[1169]: [ply-event-loop.c:759]               ply_event_loop_stop_watching_fd:stopping watching fd 6
plymouth[1169]: [ply-event-loop.c:775]               ply_event_loop_stop_watching_fd:removing destination for fd 6
systemd[1]: Received SIGRTMIN+21 from PID 113 (plymouthd).
plymouth[1169]: [ply-event-loop.c:759]               ply_event_loop_stop_watching_fd:stopping watching fd 6
plymouth[1169]: [ply-event-loop.c:775]               ply_event_loop_stop_watching_fd:removing destination for fd 6
plymouth[1169]: [./ply-boot-client.c:795]        ply_boot_client_detach_from_event_loop:detaching from event loop
plymouth[1170]: [ply-event-loop.c:1060]   ply_event_loop_handle_disconnect_for_source:calling disconnected_handler 0x403310 for fd 6
plymouth[1170]: [./plymouth.c:414]                                 on_disconnect:disconnect
plymouth[1170]: [ply-event-loop.c:1064]   ply_event_loop_handle_disconnect_for_source:done calling disconnected_handler 0x403310 for fd 6
plymouth[1170]: [ply-event-loop.c:1144]   ply_event_loop_free_destinations_for_source:freeing destination (0, (nil), 0x403310) of fd 6
plymouth[1170]: [./ply-boot-client.c:795]        ply_boot_client_detach_from_event_loop:detaching from event loop
plymouthd[19722]: [main.c:1891]                               check_verbosity:redirecting debug output to /dev/tty63
plymouth[19728]: [ply-event-loop.c:759]               ply_event_loop_stop_watching_fd:stopping watching fd 6
plymouth[19728]: [ply-event-loop.c:775]               ply_event_loop_stop_watching_fd:removing destination for fd 6
plymouth[19728]: [ply-event-loop.c:759]               ply_event_loop_stop_watching_fd:stopping watching fd 6
plymouth[19728]: [ply-event-loop.c:775]               ply_event_loop_stop_watching_fd:removing destination for fd 6
plymouth[19728]: [./ply-boot-client.c:795]        ply_boot_client_detach_from_event_loop:detaching from event loop



Thanks. I'm really interested to getting this to work so I would appreciate any tips on how to debug it further.

You have a splash delay of 9 which means it won't try to show the splash for 9 seconds.  shutdown probably takes less than 9 seconds in most cases. Try lowering the splash delay and see if that makes shutdown more reliable.

Now onto the boot log:
[./plugin.c:1003]                                  query_device:Could not get card resources
^-- That's weird. you have drm device but you can't query it.  what sort of graphics hardware do you have?  could be a driver bug there.  I'd suggest adding drm.debug=7 on the kernel command line and see if that helps make things clearer



[ply-device-manager.c:748]                      create_devices_from_udev:Looking for devices from udev
[ply-device-manager.c:273]                  create_devices_for_subsystem:creating objects for drm devices
[ply-device-manager.c:273]                  create_devices_for_subsystem:creating objects for frame buffer devices
[ply-device-manager.c:756]                      create_devices_from_udev:Creating non-graphical devices, since there's no suitable graphics hardware
^-- so despite the devices showing up in udev before, they're not later, after coldplug completes. Is udev crashing or getting killed ? is the graphics driver getting unloaded?

oh i just realized you're using the proprietary nvidia drivers.  The proprietary nvidia drivers don't support kernel modesetting. I'm a little confused how it could be working under any circumstance for you.

(In reply to Ray Strode [halfline] from comment #4)
> You have a splash delay of 9 which means it won't try to show the splash for
> 9 seconds.  shutdown probably takes less than 9 seconds in most cases. Try
> lowering the splash delay and see if that makes shutdown more reliable.
 
Indeed, I set it to 0 and now it always works on reboot/shutdown, only it first
starts in text mode (3 triangles) and then switches to correct
colourful theme http://i.imgur.com/7oqIdTw.jpg

I didn't find anywhere what exactly means ShowDelay and so I assumed it
means extra delay for how long to show splash. That's why I increased it
hoping I would see it for longer.

> Now onto the boot log:
> [./plugin.c:1003]                                  query_device:Could not
> get card resources
> ^-- That's weird. you have drm device but you can't query it.  what sort of
> graphics hardware do you have?  could be a driver bug there.  I'd suggest
> adding drm.debug=7 on the kernel command line and see if that helps make
> things clearer

I've Nvidia GTX 650 Ti with proprietary nvidia drivers 352.30
Here's journal with drm.debug https://paste.kde.org/ps1ko65wn

> [ply-device-manager.c:748]                     
> create_devices_from_udev:Looking for devices from udev
> [ply-device-manager.c:273]                 
> create_devices_for_subsystem:creating objects for drm devices
> [ply-device-manager.c:273]                 
> create_devices_for_subsystem:creating objects for frame buffer devices
> [ply-device-manager.c:756]                     
> create_devices_from_udev:Creating non-graphical devices, since there's no
> suitable graphics hardware
> ^-- so despite the devices showing up in udev before, they're not later,
> after coldplug completes. Is udev crashing or getting killed ? is the
> graphics driver getting unloaded?

I don't think, I don't have any crash reports, no erorrs in journal.

(In reply to Ray Strode [halfline] from comment #5)
> oh i just realized you're using the proprietary nvidia drivers.  The
> proprietary nvidia drivers don't support kernel modesetting. I'm a little
> confused how it could be working under any circumstance for you.

I actually figured out what's going on. When rebooting/shutting down then
nvidia driver is unloaded and then Plymouth uses framebuffer to display
splash but before nvidia is unloaded it uses that text splash.

There's still some kind of bug that prevents Plymouth from using
framebuffer when starting up even when no driver is loaded, I tested that
if I remove nvidia/nouveau drivers and just leave (U)EFI framebuffer
then Plymouth doesn't display anything on boot (not even that text mode like
it does with nvidia driver) but works correctly on reboot/shutdown. Here's a
plymouth debug log https://paste.kde.org/pwrpkudnh
That (U)EFI framebuffer (/dev/fb0) works fine I tested with fbv that can
disaply images. Also I'm using rEFInd boootloader which displays pretty
boot menu http://i.imgur.com/XjTvjQF.jpg

From kernel log can see that everything is good

kernel: Console: colour dummy device 80x25
kernel: console [tty0] enabled
kernel: vgaarb: setting as boot device: PCI:0000:01:00.0
kernel: vgaarb: device added: PCI:0000:01:00.0,decodes=io+mem,owns=io+mem,locks=none
kernel: vgaarb: loaded
kernel: vgaarb: bridge control possible 0000:01:00.0
kernel: efifb: probing for efifb
kernel: efifb: framebuffer at 0xdf000000, mapped to 0xffffc90001000000, using 3072k, total 3072k
kernel: efifb: mode is 1024x768x32, linelength=4096, pages=1
kernel: efifb: scrolling: redraw
kernel: efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
kernel: Console: switching to colour frame buffer device 128x48
kernel: fb0: EFI VGA frame buffer device

Only for some reason kernel switches to text console even when rEFInd
quits and starts kernel in (U)EFI graphic mode. Any idea how to make it
stay in that so that Plymouth could directly use it and wouldn't have
any mode switches?

Also by the way I managed to get another crash, but this happend only
few times and not sure what caused it.

#0  0x0000000000000000 in ?? ()
#1  0x00007f9990d7d47d in ply_keyboard_new_for_renderer (renderer=renderer@entry=0xea0720) at ply-keyboard.c:139
#2  0x00007f9990d7ac24 in create_devices_for_terminal_and_renderer_type (manager=0xea04d0, device_path=0xea0240 "/dev/tty63",
    terminal=0xea0580, renderer_type=PLY_RENDERER_TYPE_AUTO) at ply-device-manager.c:675
#3  0x0000000000404f98 in load_devices (flags=PLY_DEVICE_MANAGER_FLAGS_IGNORE_UDEV, state=0x7fffbde81f50) at main.c:1073
#4  main (argc=<optimized out>, argv=<optimized out>) at main.c:2305


Anyway I worked around this plymouth bug that it doesn't work on boot
for (U)EFI console. I modified kernel a bit so that efifb is
a module instead of builtin. Then I wrote this switch-modules.sh
script https://gist.github.com/davispuh/84674924dff1db3e7844 and 
switch-nvidia.service https://gist.github.com/davispuh/0eba8609e333b82114d0

With them I boot using nouveau and see nice splash :) then unload nouveau
and load efifb and nvidia driver. And on reboot/shutdown unload nvidia.
This way now I got Plymouth fully working even when using nvidia
drivers :) It's not ideal because there are several mode switches
firstly from bootloader to kernel and then from Plymouth to display
manager. How does Plymouth determine when it should quit and system
is booted? I think it quits way too early for me and I've quite
long time black screen after it finishes before display manager
starts.

I played a bit with nouveau/efifb/nvidia module loading/unloading
and it actually works fine. When booted with efifb I've 1024x768
console reslution, then when loading nouveau it switches to native
resolution 2560x1440 and then when unloading noueveau and loading
efifb, console switches back to 1024x768 only it's all upscaled to
2560x1440 so you can see it very pixelated, that's because when
unloading nouveau it doesn't change GPU resolution back. I haven't
found how to make nouevau change GPU resolution so that before
unloading it I could set it back. But then if I unload nouevau
and load efifb and nvidia I get correct GPU resolution back again
and perfectly working console. Also there's some bug in noueveau
that if I load nvidia, unload nvidia and load nouveau then
it crashes and screen gets garbled.

nouveau E[   PDISP][0000:01:00.0][0xc000917e] fini: 0x40020088

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/plymouth/plymouth/issues/21.