sfwbar
sfwbar copied to clipboard
LBCrion
segfault in css_custom_handle after upgrading to v1.0_beta14
Is this with a default config or a custom one, if it's the later, can you post it please?
Also, would it be possible to run bt full in gdb to get detailed backtrace of this segfault?
bt full: sfwbar-btfull.txt
About the config - I'm not sure! I saw the crash in my normal setup (which is heavily apparmored and sandboxed), but that didn't leave a core (because: security). I then reran outside my normal setup with ulimits to get a core, but am note sure if I gave it the right config (I have several from all of the times we tried different things). Let me try it with different configs to see which segfault and which don't.
It does NOT segfault this way with the default config that accompanies beta14.
Maybe I should just patch the beta14 config with my changes, instead of starting with a pre-beta13 config?
I did get it to segfault with my normal config, which is: sfwbar.config.txt
And the bt full from that is: sfwbar-btfull.txt
This should be fixed in the latest git. It was caused by an invalid CSS property in the config: -GtkWidget-halign: left; and a bug in handling invalid alignment type in sfwbar. Valid alignment values are start, end, center, fill and baseline. I expect you want start in the button#app CSS section.
Of course sfwbar shouldn't crash on an invalid property.
Pulled that fix, and rebuilt - and it does work without fixing the config. But I'll fix the config as well.
Thanks!
BTW - on a completely different topic - my recent project inspired by our ShowDesktop debacle: https://gitlab.freedesktop.org/jonleivent/waydapt
Also noticed SetMirror when I started sfwbar up with the config from beta14. I like it, but noticed it isn't in the doc.
Thank you for flagging this! This needs to be documented of course. I added it to the current git.
BTW - on a completely different topic - my recent project inspired by our ShowDesktop debacle: https://gitlab.freedesktop.org/jonleivent/waydapt
That's really cool. I guess once the DLLs to handle the desired functionality are written, one can expose access to them via an IPC for taskbars to talk to?
That's really cool. I guess once the DLLs to handle the desired functionality are written, one can expose access to them via an IPC for taskbars to talk to?
Or have the taskbar actually be one or more of the DLLs. It's interesting to think about what a taskbar could do beyond the limits of toplevel_manager if it could see and alter the message traffic between the compositor and clients.
Still a lot of work to do, but the proof of concept is running - it's my sandboxed desktop's clipboard manager.