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

Wf-backgroud crashes after disconnecting external monitor. #219

Closed
mark-herbert42 opened this issue Mar 13, 2024 · 8 comments
Closed

Wf-backgroud crashes after disconnecting external monitor. #219

mark-herbert42 opened this issue Mar 13, 2024 · 8 comments

Comments

@mark-herbert42
Copy link

Connect external monitor to the latop.

Backgroud image is perfectly painted on it straigh away.

Disconnect external monitor.

Wait till the cycle timout event happens and wf-background will load the next wallpaper. It changes wallpaper on the main screen and crahes almost immediately - looks like it is attempting to paint new wallpaper on the disconnected output.

@mark-herbert42
Copy link
Author

Comiped it with buidtype=debug.

In log -
Loaded /usr/share/backgrounds/dark/2.jpg
Loaded /usr/share/backgrounds/dark/2.jpg
Loaded /usr/share/backgrounds/dark/2.jpg

Fist time it loaded background when I re-start it in terminal after crash. Second time it reloaded it when I connected the monitor and system started negotiation for monitor mode. Third time - when monitor mode was selected and it started show the picture.

So wf-background is receving signals for monitor change when monitor is connected. But when I disconnected monitor - it did not reload the wallpaper. Next time it reloaded next wallpaper on timeut

Loaded /usr/share/backgrounds/dark/17.jpg

(wf-background:46816): Gtk-CRITICAL **: 14:08:04.374: gtk_widget_get_allocated_width: assertion 'GTK_IS_WIDGET (widget)' failed

(wf-background:46816): Gtk-CRITICAL **: 14:08:04.374: gtk_widget_get_allocated_height: assertion 'GTK_IS_WIDGET (widget)' failed

(wf-background:46816): GdkPixbuf-CRITICAL **: 14:08:04.374: gdk_pixbuf_new_from_file_at_scale: assertion 'width > 0 || width == -1' failed

(wf-background:46816): Gtk-CRITICAL **: 14:08:04.374: gtk_widget_get_allocated_width: assertion 'GTK_IS_WIDGET (widget)' failed

(wf-background:46816): Gtk-CRITICAL **: 14:08:04.374: gtk_widget_get_allocated_height: assertion 'GTK_IS_WIDGET (widget)' failed

(wf-background:46816): GdkPixbuf-CRITICAL **: 14:08:04.374: gdk_pixbuf_new_from_file_at_scale: assertion 'width > 0 || width == -1' failed

(wf-background:46816): Gtk-CRITICAL **: 14:08:04.374: gtk_widget_get_allocated_width: assertion 'GTK_IS_WIDGET (widget)' failed

(wf-background:46816): Gtk-CRITICAL **: 14:08:04.374: gtk_widget_get_allocated_height: assertion 'GTK_IS_WIDGET (widget)' failed

(wf-background:46816): GdkPixbuf-CRITICAL **: 14:08:04.374: gdk_pixbuf_new_from_file_at_scale: assertion 'width > 0 || width == -1' failed
free(): invalid pointer
Aborted (core dumped)

@mark-herbert42
Copy link
Author

(gdb) bt
#0 0x00007f23144d819c in ??? () at /usr/lib64/libc.so.6
WayfireWM/wayfire#1 0x00007f2314487be2 in raise () at /usr/lib64/libc.so.6
WayfireWM/wayfire#2 0x00007f23144704ed in abort () at /usr/lib64/libc.so.6
WayfireWM/wayfire#3 0x00007f231447155c in ??? () at /usr/lib64/libc.so.6
WayfireWM/wayfire#4 0x00007f23144e1ff5 in ??? () at /usr/lib64/libc.so.6
WayfireWM/wayfire#5 0x00007f23144e42bc in ??? () at /usr/lib64/libc.so.6
WayfireWM/wayfire#6 0x00007f23144e6c8f in free () at /usr/lib64/libc.so.6
WayfireWM/wayfire#7 0x0000555dc056ab67 in std::__new_allocator<std::__cxx11::basic_string<char, std::char_traits, std::allocator > >::destroy<std::__cxx11::basic_string<char, std::char_traits, std::allocator > >
(__p=0x555dc192b2d0, this=0x555dc1838620) at /usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/bits/new_allocator.h:198
WayfireWM/wayfire#8 std::allocator_traits<std::allocator<std::__cxx11::basic_string<char, std::char_traits, std::allocator > > >::destroy<std::__cxx11::basic_string<char, std::char_traits, std::allocator > > (__p=0x555dc192b2d0, __a=...)
at /usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/bits/alloc_traits.h:558
WayfireWM/wayfire#9 std::vector<std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::allocator<std::__cxx11::basic_string<char, std::char_traits, std::allocator > > >::_M_erase
(this=0x555dc1838620, __position="f-\033[1;35mCRITICAL\033[0m **: \033[34m14:") at /usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/bits/vector.tcc:187
https://github.com/WayfireWM/wayfire/pull/10 0x0000555dc05682cf in std::vector<std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::allocator<std::__cxx11::basic_string<char, std::char_traits, std::allocator > > >::erase
(this=0x555dc1838620, __position="f-\033[1;35mCRITICAL\033[0m **: \033[34m14:") at /usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/bits/stl_vector.h:1532
https://github.com/WayfireWM/wayfire/issues/11 0x0000555dc0563fab in WayfireBackground::load_next_background (this=0x555dc1838500, pbuf=..., path='\000' <repeats 25 times>, "j\210\301]U\000", <incomplete sequence \340>) at ../src/background/background.cpp:206
https://github.com/WayfireWM/wayfire/issues/12 0x0000555dc056383d in WayfireBackground::change_background (this=0x555dc1838500) at ../src/background/background.cpp:115
https://github.com/WayfireWM/wayfire/pull/13 0x0000555dc056ffbe in sigc::bound_mem_functor0<bool, WayfireBackground>::operator() (this=0x555dc19d44f8) at /usr/include/sigc++-2.0/sigc++/functors/mem_fun.h:1991
https://github.com/WayfireWM/wayfire/pull/14 0x0000555dc056f232 in sigc::adaptor_functor<sigc::bound_mem_functor0<bool, WayfireBackground> >::operator() (this=0x555dc19d44f0) at /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256
https://github.com/WayfireWM/wayfire/issues/15 0x0000555dc056dc16 in sigc::internal::slot_call0<sigc::bound_mem_functor0<bool, WayfireBackground>, bool>::call_it (rep=0x555dc19d44c0) at /usr/include/sigc++-2.0/sigc++/functors/slot.h:136
https://github.com/WayfireWM/wayfire/issues/16 0x00007f2314c35e82 in ??? () at /usr/lib64/libglibmm-2.4.so.1
https://github.com/WayfireWM/wayfire/pull/17 0x00007f2314d14d5a in ??? () at /usr/lib64/libglib-2.0.so.0
https://github.com/WayfireWM/wayfire/pull/18 0x00007f2314d10d68 in ??? () at /usr/lib64/libglib-2.0.so.0
https://github.com/WayfireWM/wayfire/issues/19 0x00007f2314d14087 in ??? () at /usr/lib64/libglib-2.0.so.0
https://github.com/WayfireWM/wayfire/issues/20 0x00007f2314d146ac in g_main_context_iteration () at /usr/lib64/libglib-2.0.so.0
https://github.com/WayfireWM/wayfire/issues/21 0x00007f23136363ad in g_application_run () at /usr/lib64/libgio-2.0.so.0
https://github.com/WayfireWM/wayfire/issues/22 0x0000555dc0572256 in WayfireShellApp::run (this=0x555dc175bfd0) at ../src/util/wf-shell-app.cpp:177
https://github.com/WayfireWM/wayfire/issues/23 0x0000555dc0566f54 in WayfireBackgroundApp::create (argc=1, argv=0x7ffd48a1a398) at ../src/background/background.cpp:335
https://github.com/WayfireWM/wayfire/pull/24 0x0000555dc0564ff3 in main (argc=1, argv=0x7ffd48a1a398) at ../src/background/background.cpp:362
(gdb)

ammen99 added a commit that referenced this issue Mar 13, 2024
@ammen99
Copy link
Member

ammen99 commented Mar 13, 2024

Can you try the PR #220, I think that should be enough to fix the crash.

ammen99 added a commit that referenced this issue Mar 13, 2024
@mark-herbert42
Copy link
Author

It does not crash anymore. But behaves differently than I expected - now the both monitors are not in sync with the wllpaper image, and each monitor has its own timer. For external monitor the timer runs only when it is connected, Anyway that's not a bug, that's a way it works.

@ammen99
Copy link
Member

ammen99 commented Mar 13, 2024

It does not crash anymore. But behaves differently than I expected - now the both monitors are not in sync with the wllpaper image, and each monitor has its own timer. For external monitor the timer runs only when it is connected, Anyway that's not a bug, that's a way it works.

Yeah I can see that. I suppose we can fix them to be in sync - feel free to send a PR if you manage to patch it.

@ammen99
Copy link
Member

ammen99 commented Mar 13, 2024

Also thanks for testing :)

ammen99 added a commit that referenced this issue Mar 13, 2024
@ArmanHayots
Copy link

@ammen99 , is there any way to get logs without building debug version from scratch?

@ammen99
Copy link
Member

ammen99 commented Apr 11, 2024

@ammen99 , is there any way to get logs without building debug version from scratch?

No, release builds explicitly remove most source code information and you cannot easily find how the crash occurs without this information.

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

No branches or pull requests

3 participants