Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Errors in config options can cause renderer to crash without notice #1593

Closed
bennofs opened this issue Jan 10, 2019 · 3 comments
Closed

Errors in config options can cause renderer to crash without notice #1593

bennofs opened this issue Jan 10, 2019 · 3 comments
Labels

Comments

@bennofs
Copy link
Contributor

bennofs commented Jan 10, 2019

Describe the issue

If you have an error in a config option that is accessed in the renderer::renderer component constructor, the renderer not be constructed and no feedback is given to the user (and because the renderer won't be constructed, no bar is drawn).

Expected behavior:

There should be a clear error presented to the user about what is wrong and polybar should either exit or assume a reasonable default.

Actual behavior:

Polybar (the process) keeps running but no bar is visible.

Was it working before?
Haven't tested this (didn't experience it with my own configuration)

To Reproduce

A minimal but complete config with which the problem occurs:

[bar/example]
modules-left = title
fixed-center = ${vars.true}

[module/title]
type = internal/xwindow

Polybar Log

(The "EXCEPTION CAUGHT" and some other logs are printed by debug logging I patched into my polybar and is not actually there in master):

* Loading config: /tmp/c
- config: Current bar section: [bar/example]
warn: No monitor specified, using "eDP-1"
* Loaded monitor eDP-1 (1920x1080+0+0)
* Bar geometry: 1920x24+0+0
- bar: Attach X event sink
- bar: Attach signal receiver
- controller: Install signal handler
- controller: Setup user-defined modules
* Starting application
- controller: Main thread id = 1
* Starting module/title
* Entering event loop (thread-id=1)
- module/title: Thread id = 2
* Eventqueue worker (thread-id=3)
- bar: Create renderer
- renderer: Get TrueColor visual
- renderer: Allocate colormap
- renderer: Allocate output window
- renderer: Allocate window pixmaps
- renderer: Allocate graphic contexts
- renderer: Allocate alignment blocks
- renderer: Allocate cairo components
- renderer: Load fonts
* Configured DPI = 96x96
warn: No fonts specified, using fallback font "fixed"
- load font start
* Loaded font "fixed" (name=DejaVu Sans, offset=0, file=/usr/share/fonts/TTF/DejaVuSans.ttf)
- load font done
- all fonts done
- doing transparency stuff
- done transparency stuff
- 1
- 2
- 3
- 4
- 5
EXCEPTION CAUGHT: The reference ${vars.true} does not exist (no fallback set)

Environment:

  • WM: i3
  • Output of polybar -vvv:
polybar 3.0.5-338-gb728fea

Features: +alsa +curl +i3 +mpd +network(libnl) +pulseaudio +xkeyboard

X extensions: +randr (+monitors) -render -damage -sync +composite +xkb +xrm +xcursor

Build type: Debug
Compiler: /usr/bin/c++
Compiler flags:  -Wall -Wextra -Werror -Wno-noexcept-type -pedantic -pedantic-errors
Linker flags:
@bennofs
Copy link
Contributor Author

bennofs commented Jan 10, 2019

The issue is this part of the code where the exception is ignored (catch (...) {}):

https://github.com/jaagr/polybar/blob/b728fea5be06733c040fc02b2f629863627bfa04/include/events/signal_emitter.hpp#L25-L37

Then, this line in renderer could throw an exception if the config option fails to evaluate:

https://github.com/jaagr/polybar/blob/b728fea5be06733c040fc02b2f629863627bfa04/src/components/renderer.cpp#L181

@patrick96
Copy link
Member

I noticed the signal handler swallowing all exceptions (see #1451).

I have changed the code to log an error on every exception. But I noticed that exceptions get thrown in quite a few places and not caught until the signal emitter does (not really optimal), will see what I can do about that.

patrick96 added a commit to patrick96/polybar that referenced this issue Jan 14, 2019
If any signal receiver throws an exception for any reason after
receiving a signal, no one would find out about it because the signal
emitter just ignored exceptions

Also actually delivering the signal caused some exceptions because not
all signals have a receiver.

Resolves polybar#1593
@patrick96
Copy link
Member

Alright, wasn't that bad to fix.

@patrick96 patrick96 added the bug label Jan 14, 2019
patrick96 added a commit that referenced this issue Feb 5, 2019
If any signal receiver throws an exception for any reason after
receiving a signal, no one would find out about it because the signal
emitter just ignored exceptions

Also actually delivering the signal caused some exceptions because not
all signals have a receiver.

Resolves #1593
doronbehar pushed a commit to doronbehar/polybar that referenced this issue Jun 16, 2019
If any signal receiver throws an exception for any reason after
receiving a signal, no one would find out about it because the signal
emitter just ignored exceptions

Also actually delivering the signal caused some exceptions because not
all signals have a receiver.

Resolves polybar#1593
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants