Hi, Xfwm4 is crashing due to: A) Press the screen lock button from the manjaro start-menue and unlock it with your password B) 1) automated screen-lock locks the screen after x minutes (OK) 2) screensaver comes after x minutes and screen is going to be black. (OK) 3) Everytime i unlock my locked screen (after the screensaver kicked in) i got this: systemd-coredump (NOT OK) It is reproducible: regards LF Apr 30 09:44:36 lightdm[1475]: gkr-pam: unable to locate daemon control file Apr 30 09:44:40 systemd-coredump[1498]: Process 1089 (xfwm4) of user 1000 dumped core. Stack trace of thread 1089: #0 0x00007ff3bc497186 n/a (libglib-2.0.so.0) #1 0x00007ff3bc494f5c g_log_writer_default (libglib-2.0.so.0) #2 0x00007ff3bc48ba49 g_log_structured_array (libglib-2.0.so.0) #3 0x00007ff3bc493f0d g_log_structured_standard (libglib-2.0.so.0) #4 0x00007ff3bc7f054e n/a (libgdk-3.so.0) #5 0x00007ff3bc7fd6e5 n/a (libgdk-3.so.0) #6 0x00007ff3bc11852a _XError (libX11.so.6) #7 0x00007ff3bc1153f8 n/a (libX11.so.6) #8 0x00007ff3bc1154a5 n/a (libX11.so.6) #9 0x00007ff3bc116410 _XReply (libX11.so.6) #10 0x00007ff3bcfb9742 XIQueryDevice (libXi.so.6) #11 0x00007ff3bc7ed1bd n/a (libgdk-3.so.0) #12 0x00007ff3bc7f836d n/a (libgdk-3.so.0) #13 0x00007ff3bc7f7e36 n/a (libgdk-3.so.0) #14 0x00007ff3bc7c0ea2 gdk_display_get_event (libgdk-3.so.0) #15 0x00007ff3bc7f7aa4 n/a (libgdk-3.so.0) #16 0x00007ff3bc49d7bf g_main_context_dispatch (libglib-2.0.so.0) #17 0x00007ff3bc49f739 n/a (libglib-2.0.so.0) #18 0x00007ff3bc4a06d2 g_main_loop_run (libglib-2.0.so.0) #19 0x00007ff3bcac8e6f gtk_main (libgtk-3.so.0) #20 0x000055a3ba8ef765 n/a (xfwm4) #21 0x00007ff3bbbc7ce3 __libc_start_main (libc.so.6) #22 0x000055a3ba8ef95e n/a (xfwm4) Stack trace of thread 1101: #0 0x00007ff3bbc940d1 __poll (libc.so.6) #1 0x00007ff3bc49f690 n/a (libglib-2.0.so.0) #2 0x00007ff3bc49f77e g_main_context_iteration (libglib-2.0.so.0) #3 0x00007ff3bc49f7d2 n/a (libglib-2.0.so.0) #4 0x00007ff3bc47ac21 n/a (libglib-2.0.so.0) #5 0x00007ff3bbd70a92 start_thread (libpthread.so.0) #6 0x00007ff3bbc9ecd3 __clone (libc.so.6) Stack trace of thread 1235: #0 0x00007ff3bbd76bac pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0) #1 0x00007ff3b39721e4 n/a (nouveau_dri.so) #2 0x00007ff3b3971f08 n/a (nouveau_dri.so) #3 0x00007ff3bbd70a92 start_thread (libpthread.so.0) #4 0x00007ff3bbc9ecd3 __clone (libc.so.6) Stack trace of thread 1102: #0 0x00007ff3bbc940d1 __poll (libc.so.6) #1 0x00007ff3bc49f690 n/a (libglib-2.0.so.0) #2 0x00007ff3bc4a06d2 g_main_loop_run (libglib-2.0.so.0) #3 0x00007ff3bb5ab568 n/a (libgio-2.0.so.0) #4 0x00007ff3bc47ac21 n/a (libglib-2.0.so.0) #5 0x00007ff3bbd70a92 start_thread (libpthread.so.0) #6 0x00007ff3bbc9ecd3 __clone (libc.so.6) -- Subject: Speicherabbild für Prozess 1089 (@COREDUMP_COMM) generiert -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Documentation: man:core(5) -- -- Prozess 1089 (xfwm4) ist abgebrochen worden und -- ein Speicherabbild wurde generiert. -- -- Üblicherweise ist dies ein Hinweis auf einen Programmfehler und sollte -- als Fehler dem jeweiligen Hersteller gemeldet werden.
More testing and HW info you can find: https://forum.manjaro.org/t/systemd-coredump-2529-process-2326-xfwm4-of-user-1000-dumped-core-maybe-because-of-lightdm-2482-gkr-pam-unable-to-locate-daemon-control-file/85219
I think the Xwfm4 crash is somehow realted to Apr 30 09:44:36 lightdm[1475]: gkr-pam: unable to locate daemon control file which happens a short time before?
Manjaro TESTING BRANCH: Aha, no xwfm4 crash with kernel 4.14.114 but still gkr-pam: unable to locate daemon control file: Manjaro STABLE BRANCH: no xwfm4 crash with kernel 5.0.9 but 2 times the: gkr-pam: unable to locate daemon control file:
gkr-pam issue is completely unrelated to xfwm4.
(In reply to Olivier Fourdan from comment #4) > gkr-pam issue is completely unrelated to xfwm4. ok, then what will be the next steps to investigate? LF
That backtrace is useless due to lack of debugsymbols. This is likely an abort() due to an X11 error, there needs to be some environment variable set for the process to report errors syncron, instead of asyncron.
Hmmm... can i install some kind of xfce developer package, to get this debugsymbols? Or how can i find out these environment variables? LF
https://superuser.com/questions/485499/how-to-set-environment-variables-for-xfce-windowing-environment leads to https://wiki.archlinux.org/index.php/Xfce#Session
That is something I do not know. Also, is there actually a core dump? Just open it with 'gdb --core=core' and see if anything passes a message around. This message will contain the required steps to enable synchronized logging.
So i need to install GNU GDB Debugger first? And then i guess i must connect systemd-coredump[2810]: Process 2532 (xfwm4) of user 1000 dumped core. with gdb? LF
gdb --core=core GNU gdb (GDB) 8.2.1 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word". /home/user/core: No such file or directory. (gdb)
It is saying: /home/user/core: No such file or directory. ?
Try 'coredumpctl list', which is supposed to give a list of recent crashes. Then try 'coredump gdb 2241', if pid of the crashed process was '2241'. It will be of no much use if the provided packages do not have debug symbols available. In this case it is required for the libraries listed in the backtrace, like libglib-2.0.so.0 and whatever else is listed in comment#0
This is cool! coredumpctl list TIME PID UID GID SIG COREFILE EXE Tue 2019-04-23 21:21:58 CEST 892 0 0 6 missing /usr/bin/cupsd Tue 2019-04-23 22:02:48 CEST 1060 1000 1001 11 missing /usr/bin/pamac-manager Wed 2019-04-24 13:00:54 CEST 1924 1000 1001 5 missing /usr/bin/light-locker Wed 2019-04-24 22:38:11 CEST 1632 1000 1001 5 missing /usr/bin/light-locker Fri 2019-04-26 00:01:05 CEST 9186 0 0 6 missing /usr/bin/crond Fri 2019-04-26 12:24:31 CEST 682 1000 1001 5 missing /usr/bin/xfwm4 Fri 2019-04-26 12:46:59 CEST 1054 1000 1001 5 missing /usr/bin/xfwm4 Sat 2019-04-27 12:40:49 CEST 692 1000 1001 5 missing /usr/bin/xfwm4 Sat 2019-04-27 12:49:36 CEST 698 1000 1001 6 missing /usr/bin/thunar Sat 2019-04-27 13:23:36 CEST 5966 1000 1001 5 missing /usr/bin/xfwm4 Sat 2019-04-27 14:38:32 CEST 710 1000 1001 5 missing /usr/bin/xfwm4 Sat 2019-04-27 14:51:46 CEST 1041 1000 1001 5 missing /usr/bin/xfwm4 Mon 2019-04-29 11:30:22 CEST 709 1000 1001 5 present /usr/bin/xfwm4 Mon 2019-04-29 18:17:11 CEST 690 1000 1001 5 present /usr/bin/xfwm4 Mon 2019-04-29 20:42:49 CEST 699 1000 1001 5 present /usr/bin/xfwm4 Mon 2019-04-29 21:08:40 CEST 2326 1000 1001 5 present /usr/bin/xfwm4 Mon 2019-04-29 23:32:37 CEST 620 1000 1001 5 present /usr/bin/xfwm4 Tue 2019-04-30 09:44:40 CEST 1089 1000 1001 5 present /usr/bin/xfwm4 Tue 2019-04-30 18:37:08 CEST 690 1000 1001 5 present /usr/bin/xfwm4 Tue 2019-04-30 19:13:42 CEST 1043 1000 1001 5 present /usr/bin/xfwm4 Wed 2019-05-01 12:26:10 CEST 686 1000 1001 5 present /usr/bin/xfwm4 Wed 2019-05-01 12:52:15 CEST 2532 1000 1001 5 present /usr/bin/xfwm4 aha.... (no debugging symbols found)...done. )-: so i need the libs you've said... coredumpctl gdb 2532 PID: 2532 (xfwm4) ... ... GNU gdb (GDB) 8.2.1 ... Reading symbols from /usr/bin/xfwm4...(no debugging symbols found)...done. [New LWP 2532] [New LWP 2533] [New LWP 2534] [New LWP 2543] [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". Core was generated by `xfwm4 --display :0.0 --sm-client-id 2e0b60d2f-c2e4-484a-8440-34a370cc8374'. Program terminated with signal SIGTRAP, Trace/breakpoint trap. #0 0x00007fcd059c1186 in ?? () from /usr/lib/libglib-2.0.so.0 [Current thread is 1 (Thread 0x7fcd039be980 (LWP 2532))] (gdb)
(In reply to olaf from comment #13) > Try 'coredumpctl list', which is supposed to give a list of recent crashes. > Then try 'coredump gdb 2241', if pid of the crashed process was '2241'. > > It will be of no much use if the provided packages do not have debug symbols > available. In this case it is required for the libraries listed in the > backtrace, like libglib-2.0.so.0 and whatever else is listed in comment#0 mmmhh? What exactly is required for the libraries? a) -enabled debug symbols? (so maybe our Manjaro dev team can provide me with that?) b) -also to be listed in coredumpctl list ?
there is most likely a glib2-debuginfo package somewhere, depending on how they are named. Check the Manjaro documentation for debuginfo packages.
A core file won't help, it is not a segmentation, it's an abort triggered by an XError. And a backtrace will just show you were the issue was detected, not when it was created (X protocol is asynchronous). And forcing it to run synchronously will avoid the error. So for now I would be curious to get the actual request that triggered the XError, which should be seen from the xfwm4 logs. Try this: 1. Open a terminal and run $ xfwm4 --replace & 2. Reproduce the problem 3. Copy the error message in its entirety in this bug “The program 'xfwm4' received an X Window System error. This probably reflects a bug in the program. The error was 'blah blah blah'. (Details: serial <some number> error_code <some number> request_code <some number> minor_code <some number>)”
(In reply to Olivier Fourdan from comment #17) > A core file won't help, it is not a segmentation, it's an abort triggered by > an XError. And a backtrace will just show you were the issue was detected, > not when it was created (X protocol is asynchronous). And forcing it to run > synchronously will avoid the error. > > So for now I would be curious to get the actual request that triggered the > XError, which should be seen from the xfwm4 logs. > > Try this: > > 1. Open a terminal and run > > $ xfwm4 --replace & > > 2. Reproduce the problem > > 3. Copy the error message in its entirety in this bug > > “The program 'xfwm4' received an X Window System error. > This probably reflects a bug in the program. > The error was 'blah blah blah'. > (Details: serial <some number> error_code <some number> request_code > <some number> minor_code <some number>)” OK, where can i find the xfwm4 logs.? /var/logs/ no xfwm4 file there cat Xorg.0.log | grep xfwm4 no data .config/xfce4]$ ls desktop helpers.rc help.rc panel terminal xfce4-screenshooter xfce4-taskmanager.rc xfconf xfwm4 ....no data in xfwm4
Please read my comment 17, I asked to run xfwm4 from a terminal so you can see the logs.
ah ok, there was no output.. xfwm4 --replace & [2] 3468 [~]$ Waiting for current window manager (Xfwm4) on screen :0.0 to exit: Done
Yes, but then you have to reproduce the issue to see the error message...
yes i have produced the issue, but there was no output... hmm, i'll reboot (-;
ok it said: xfwm4 --replace & [1] 1062 [ ~]$ bash: $: Kommando nicht gefunden. which means e.g.: [ ~]$ bash: $: command not found and it produced the usual backtrace... Mai 02 13:08:49 lightdm[1133]: gkr-pam: unable to locate daemon control file Mai 02 13:08:53 systemd-coredump[1138]: Process 693 (xfwm4) of user 1000 dumped core. Stack trace of thread 693: #0 0x00007f8e14cac186 n/a (libglib-2.0.so.0) #1 0x00007f8e14ca9f5c g_log_writer_default (libglib-2.0.so.0) #2 0x00007f8e14ca0a49 g_log_structured_array (libglib-2.0.so.0) #3 0x00007f8e14ca8f0d g_log_structured_standard (libglib-2.0.so.0) #4 0x00007f8e1500554e n/a (libgdk-3.so.0) #5 0x00007f8e150126e5 n/a (libgdk-3.so.0) #6 0x00007f8e1492d52a _XError (libX11.so.6) #7 0x00007f8e1492a3f8 n/a (libX11.so.6) #8 0x00007f8e1492a4a5 n/a (libX11.so.6) #9 0x00007f8e1492b410 _XReply (libX11.so.6) #10 0x00007f8e157ce742 XIQueryDevice (libXi.so.6) #11 0x00007f8e150021bd n/a (libgdk-3.so.0) #12 0x00007f8e1500d36d n/a (libgdk-3.so.0) #13 0x00007f8e1500ce36 n/a (libgdk-3.so.0) #14 0x00007f8e14fd5ea2 gdk_display_get_event (libgdk-3.so.0) #15 0x00007f8e1500caa4 n/a (libgdk-3.so.0) #16 0x00007f8e14cb27bf g_main_context_dispatch (libglib-2.0.so.0) #17 0x00007f8e14cb4739 n/a (libglib-2.0.so.0) #18 0x00007f8e14cb56d2 g_main_loop_run (libglib-2.0.so.0) #19 0x00007f8e152dde6f gtk_main (libgtk-3.so.0) #20 0x000055dd9d0a0765 n/a (xfwm4) #21 0x00007f8e143dcce3 __libc_start_main (libc.so.6) #22 0x000055dd9d0a095e n/a (xfwm4) Stack trace of thread 703: #0 0x00007f8e144a90d1 __poll (libc.so.6) #1 0x00007f8e14cb4690 n/a (libglib-2.0.so.0) #2 0x00007f8e14cb477e g_main_context_iteration (libglib-2.0.so.0) #3 0x00007f8e14cb47d2 n/a (libglib-2.0.so.0) #4 0x00007f8e14c8fc21 n/a (libglib-2.0.so.0) #5 0x00007f8e14585a92 start_thread (libpthread.so.0) #6 0x00007f8e144b3cd3 __clone (libc.so.6) Stack trace of thread 704: #0 0x00007f8e144a90d1 __poll (libc.so.6) #1 0x00007f8e14cb4690 n/a (libglib-2.0.so.0) #2 0x00007f8e14cb56d2 g_main_loop_run (libglib-2.0.so.0) #3 0x00007f8e13dc0568 n/a (libgio-2.0.so.0) #4 0x00007f8e14c8fc21 n/a (libglib-2.0.so.0) #5 0x00007f8e14585a92 start_thread (libpthread.so.0) #6 0x00007f8e144b3cd3 __clone (libc.so.6) Stack trace of thread 838: #0 0x00007f8e1458bbac pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0) #1 0x00007f8e0b9721e4 n/a (nouveau_dri.so) #2 0x00007f8e0b971f08 n/a (nouveau_dri.so) #3 0x00007f8e14585a92 start_thread (libpthread.so.0) #4 0x00007f8e144b3cd3 __clone (libc.so.6) -- Subject: Speicherabbild für Prozess 693 (@COREDUMP_COMM) generiert -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Documentation: man:core(5) -- -- Prozess 693 (xfwm4) ist abgebrochen worden und -- ein Speicherabbild wurde generiert. -- -- Üblicherweise ist dies ein Hinweis auf einen Programmfehler und sollte -- als Fehler dem jeweiligen Hersteller gemeldet werden.
(In reply to Linuxfreak from comment #23) > ok it said: > > xfwm4 --replace & > [1] 1062 > [ ~]$ bash: $: Kommando nicht gefunden. > > which means e.g.: > > [ ~]$ bash: $: command not found Huh, did you type the dollar sign ("$")? I mean, it was just an example of the prompt, you should not copy it, just type "xfwm4 --replace &" in a terminal... As you haven't actually restarted xfwm4, no wonder you don't get the error in your terminal.
ufff sorry, ashes on my head... xfwm4 --replace & [1] 1729 []$ Waiting for current window manager (Xfwm4) on screen :0.0 to exit: Done (xfwm4:1729): Gdk-ERROR **: 13:37:28.491: The program 'xfwm4' received an X Window System error. This probably reflects a bug in the program. The error was 'RenderBadPicture (invalid Picture parameter)'. (Details: serial 47158 error_code 143 request_code 139 (RENDER) minor_code 7) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the GDK_SYNCHRONIZE environment variable to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.)
"To debug your program, run it with the GDK_SYNCHRONIZE environment" So, export this variable with any value before running xfwm4.
Well, I think this is a `BadPicture` error caused by a `XRenderFreePicture`. Thing is, I am not sure what exact version of the code Manjaro is shipping (if someone can tell where I can get the source of the Manjaro package, I'd like to hear).
(In reply to Olivier Fourdan from comment #27) > Well, I think this is a `BadPicture` error caused by a `XRenderFreePicture`. > > Thing is, I am not sure what exact version of the code Manjaro is shipping > (if someone can tell where I can get the source of the Manjaro package, I'd > like to hear). I've reported this version mismatch issue. Next week the Manjaro maintainer will have time to look at this. I'll tell you then.. LF
This is not what I am asking though, I am asking for the source code that was used to produce the binary package of xfwm4 as shipping with Manjaro.
Meanwhile, you could try as Olaf suggested: 1. Make sure to install the debug symbols (no idea how to do that with Manjaro, but it's a requirement) 2. Run xfwm4 in sync mode: GDK_SYNCHRONIZE=1 xfwm4 --replace & 3. reproduce the issue 4. Check the backtrace (it must contain symbols otherwise it will be useless to me)
(In reply to Olivier Fourdan from comment #29) > This is not what I am asking though, I am asking for the source code that > was used to produce the binary package of xfwm4 as shipping with Manjaro. ok, i'll get it.
(In reply to Olivier Fourdan from comment #30) > Meanwhile, you could try as Olaf suggested: > > 1. Make sure to install the debug symbols (no idea how to do that with > Manjaro, but it's a requirement) > > 2. Run xfwm4 in sync mode: > > GDK_SYNCHRONIZE=1 xfwm4 --replace & > > 3. reproduce the issue > > 4. Check the backtrace (it must contain symbols otherwise it will be useless > to me) ok'ill do this. meanwhile, this is always the same output: I'll try this with your latest suggestions.. LF _________________________________________________________ xfwm4 --replace & [1] 1497 [ ~]$ Waiting for current window manager (Xfwm4) on screen :0.0 to exit: Done (xfwm4:1497): Gdk-ERROR **: 11:05:45.991: The program 'xfwm4' received an X Window System error. This probably reflects a bug in the program. The error was 'RenderBadPicture (invalid Picture parameter)'. (Details: serial 33390 error_code 143 request_code 139 (RENDER) minor_code 7) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the GDK_SYNCHRONIZE environment variable to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.)
I've built xfwm4 for Manjaro from the latest code in git master, and did not strip the so we have the symbols available. Can you please do the following _exactly_ as explained below (note, the “$” sign in front of the commands represents the shell prompt and should _not_ be typed when entering the commands on your system). 1. Try the latest build as-is: $ wget http://users.xfce.org/~olivier/bug15339/xfwm4 $ chmod a+x ./xfwm4 $ ./xfwm4 --replace & Then try to reproduce the issue with light-locker just as usual, see if it fails. 2. If it still fails the same, capture a backtrace of the failure: $ GDK_SYNCHRONIZE=1 ./xfwm4 --replace & Then try to reproduce the issue with light-locker again, just as usual, and once it failed, copy the stacktrace in here.
(In reply to Linuxfreak from comment #20) > ah ok, > there was no output.. > > xfwm4 --replace & > [2] 3468 > [~]$ Waiting for current window manager (Xfwm4) on screen :0.0 to exit: Done Hi, mhhh i think i have a new behavior here. Doing xfwm4 --replace & in a terminal, does not always reproduce the crash on every try. (I think it was only once i misplaced a $ in the terminal, wich resulted in command not found. (-;) Maybe calling "xfwm4 --replace &" leads to using xfwm4 other constructors to up-start?
(In reply to Olivier Fourdan from comment #33) > I've built xfwm4 for Manjaro from the latest code in git master, and did not > strip the so we have the symbols available. > > Can you please do the following _exactly_ as explained below (note, the “$” > sign in front of the commands represents the shell prompt and should _not_ > be typed when entering the commands on your system). > > 1. Try the latest build as-is: > > $ wget http://users.xfce.org/~olivier/bug15339/xfwm4 > $ chmod a+x ./xfwm4 > $ ./xfwm4 --replace & > > Then try to reproduce the issue with light-locker just as usual, see if it > fails. > > 2. If it still fails the same, capture a backtrace of the failure: > > $ GDK_SYNCHRONIZE=1 ./xfwm4 --replace & > > Then try to reproduce the issue with light-locker again, just as usual, and > once it failed, copy the stacktrace in here. Hi Oliver, thank you, i've installed it. At the moment, with pressing the lock button from xfce start menu, leads to no crash. But i'll watch it for some days, since the last time i used the command, "xfwm4 --replace &" did not always lead to a crash. So its not clear if the new build solves thew bug or not. Also i have to look for the automated lock & screensaver after 10 minutes.. LF
Is that with or without the “GDK_SYNCHRONIZE=1” set?
Today without, the other times i had too many reboots to remember, but the first time i did export GDK_SYNCHRONIZE=1 i became something like: [1]+ Trace/Breakpoint ausgelöst (Speicherabzug geschrieben) export GDK_SYNCHRONIZE=1 but only for one time... mhh maybe the last days i had it with GDK_SYNCHRONIZE=1, where it not crashed every time i performed a xfwm4 --replace & I'll watch it.. LF
Created attachment 8481 This are the power manager settings, when the bug occures. This are the power manager settings, when the bug occures.
Created attachment 8482 This are the power manager settings, when the bug occures. This are the power manager settings, when the bug occures.
Created attachment 8483 This are the power manager settings, when the bug occures.3 This are the power manager settings, when the bug occures.3
The content of attachment 8481 has been deleted
The content of attachment 8482 has been deleted
The content of attachment 8483 has been deleted
(In reply to Linuxfreak from comment #37) > Today without, > the other times i had too many reboots to remember, > but the first time i did export GDK_SYNCHRONIZE=1 i became something like: > > [1]+ Trace/Breakpoint ausgelöst (Speicherabzug geschrieben) export > GDK_SYNCHRONIZE=1 > > but only for one time... > > mhh maybe the last days i had it with GDK_SYNCHRONIZE=1, where it not > crashed every time i performed a xfwm4 --replace & Please, can you please just stick to what I wrote in my comments, I never wrote to "export GDK_SYNCHRONIZE=1" in my comment 33, I asked to set the variable along with launching xfwm4, on the same command line. There is some logic in the what I ask, by not following the steps, you simply make the test results useless I'm afraid. (FTR, GDK_SYNCHRONIZE forces every X call to snc with the Xserver, meaning that it will most likely avoid the issue, which is why I asked to run the test *without* at first).
(In reply to olaf from comment #26) > "To debug your program, run it with the GDK_SYNCHRONIZE environment" > > So, export this variable with any value before running xfwm4. oki'll stick to it. (When i was searching for GDK_SYNCHRONIZE, i found the export GDK_SYNCHRONIZE = 1 somewhere at the forum.)
(In reply to Linuxfreak from comment #35) > (In reply to Olivier Fourdan from comment #33) > > I've built xfwm4 for Manjaro from the latest code in git master, and did not > > strip the so we have the symbols available. > > > > Can you please do the following _exactly_ as explained below (note, the “$” > > sign in front of the commands represents the shell prompt and should _not_ > > be typed when entering the commands on your system). > > > > 1. Try the latest build as-is: > > > > $ wget http://users.xfce.org/~olivier/bug15339/xfwm4 > > $ chmod a+x ./xfwm4 > > $ ./xfwm4 --replace & > > > > Then try to reproduce the issue with light-locker just as usual, see if it > > fails. > > > > 2. If it still fails the same, capture a backtrace of the failure: > > > > $ GDK_SYNCHRONIZE=1 ./xfwm4 --replace & > > > > Then try to reproduce the issue with light-locker again, just as usual, and > > once it failed, copy the stacktrace in here. > > Hi Oliver, > thank you, i've installed it. > At the moment, with pressing the lock button from xfce start menu, leads to > no crash. But i'll watch it for some days, since the last time i used the > command, "xfwm4 --replace &" did not always lead to a crash. So its not > clear if the new build solves thew bug or not. > Also i have to look for the automated lock & screensaver after 10 minutes.. > > LF So this is the output regarding to 1) ls -ll -rwxr-xr-x 1 ... ... 4995616 4. Mai 10:15 xfwm4 [...xfwm4]$ ./xfwm4 --replace & [1] 1170 [... xfwm4]$ Waiting for current window manager (Xfwm4) on screen :0.0 to exit: Done (xfwm4:1170): Gdk-ERROR **: 21:16:06.643: The program 'xfwm4' received an X Window System error. This probably reflects a bug in the program. The error was 'RenderBadPicture (invalid Picture parameter)'. (Details: serial 657088 error_code 143 request_code 139 (RENDER) minor_code 7) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the GDK_SYNCHRONIZE environment variable to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) ************************************************************************* The USB-Keyboard was not functioning anymore here... And all apps-windows had no more buttons: minimize, maximize and close. ************************************************************************* coredumpctl list Sat 2019-05-04 21:16:08 CEST 1170 1000 1001 5 present /home/.../xfwm4/xfwm4 coredumpctl gdb 1170 PID: 1170 (xfwm4) UID: 1000 (user) GID: 1001 (user) Signal: 5 (TRAP) Timestamp: Sat 2019-05-04 21:16:06 CEST (5min ago) Command Line: ./xfwm4 --replace Executable: /home/user/xfwm4/xfwm4 Control Group: /user.slice/user-1000.slice/session-1.scope Unit: session-1.scope Slice: user-1000.slice Session: 1 Owner UID: 1000 (user) Boot ID: 86ae7e81746f4fdfb0c03507fd68f7ab Machine ID: 3ae900826b38438aaa6ea18a934f9130 Hostname: ... Storage: /var/lib/systemd/coredump/core.xfwm4.1000.86ae7e81746f4fdfb0c03507fd68f7ab.1170.1556997366000000.lz4 Message: Process 1170 (xfwm4) of user 1000 dumped core. Stack trace of thread 1170: #0 0x00007fdf9fff3186 n/a (libglib-2.0.so.0) #1 0x00007fdf9fff0f5c g_log_writer_default (libglib-2.0.so.0) #2 0x00007fdf9ffe7a49 g_log_structured_array (libglib-2.0.so.0) #3 0x00007fdf9ffeff0d g_log_structured_standard (libglib-2.0.so.0) #4 0x00007fdfa053b54e n/a (libgdk-3.so.0) #5 0x00007fdfa05486e5 n/a (libgdk-3.so.0) #6 0x00007fdf9fc7252a _XError (libX11.so.6) #7 0x00007fdf9fc6f3f8 n/a (libX11.so.6) #8 0x00007fdf9fc6f4a5 n/a (libX11.so.6) #9 0x00007fdf9fc70410 _XReply (libX11.so.6) #10 0x00007fdfa0d06742 XIQueryDevice (libXi.so.6) #11 0x00007fdfa05381bd n/a (libgdk-3.so.0) #12 0x00007fdfa054336d n/a (libgdk-3.so.0) #13 0x00007fdfa0542e36 n/a (libgdk-3.so.0) #14 0x00007fdfa050bea2 gdk_display_get_event (libgdk-3.so.0) #15 0x00007fdfa0542aa4 n/a (libgdk-3.so.0) #16 0x00007fdf9fff97bf g_main_context_dispatch (libglib-2.0.so.0) #17 0x00007fdf9fffb739 n/a (libglib-2.0.so.0) #18 0x00007fdf9fffc6d2 g_main_loop_run (libglib-2.0.so.0) #19 0x00007fdfa0815e6f gtk_main (libgtk-3.so.0) #20 0x00005580e2b1cc8f n/a (/home/user/xfwm4/xfwm4) GNU gdb (GDB) 8.2.1 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /home/.../xfwm4/xfwm4...done. [New LWP 1170] [New LWP 1171] [New LWP 1172] [New LWP 1174] [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". Core was generated by `./xfwm4 --replace'. Program terminated with signal SIGTRAP, Trace/breakpoint trap. #0 0x00007fdf9fff3186 in ?? () from /usr/lib/libglib-2.0.so.0 [Current thread is 1 (Thread 0x7fdf9e408980 (LWP 1170))] (gdb) I am now applying 2)
Created attachment 8485 This are the power manager settings, when the bug occures.1 This are the power manager settings, when the bug occures.1
Created attachment 8486 This are the power manager settings, when the bug occures.2 This are the power manager settings, when the bug occures.2
Created attachment 8487 This are the power manager settings, when the bug occures.3 This are the power manager settings, when the bug occures.3
I have uploaded a new build to the same location, can you try it again? $ wget http://users.xfce.org/~olivier/bug15339/xfwm4 $ chmod a+x ./xfwm4 $ ./xfwm4 --replace & Then try to reproduce the issue with light-locker just as usual, see if it fails. (Note, please make sure to try _without_ “GDK_SYNCHRONIZE=1”)
(In reply to Olivier Fourdan from comment #33) > I've built xfwm4 for Manjaro from the latest code in git master, and did not > strip the so we have the symbols available. > > Can you please do the following _exactly_ as explained below (note, the “$” > sign in front of the commands represents the shell prompt and should _not_ > be typed when entering the commands on your system). > > 1. Try the latest build as-is: > > $ wget http://users.xfce.org/~olivier/bug15339/xfwm4 > $ chmod a+x ./xfwm4 > $ ./xfwm4 --replace & > > Then try to reproduce the issue with light-locker just as usual, see if it > fails. > > 2. If it still fails the same, capture a backtrace of the failure: > > $ GDK_SYNCHRONIZE=1 ./xfwm4 --replace & > > Then try to reproduce the issue with light-locker again, just as usual, and > once it failed, copy the stacktrace in here. Hi, i've thought i should try point 2. now? So far i was not able to reproduce the bug with point 2. GDK_SYNCHRONIZE=1 ./xfwm4 --replace & [1] 1486 [.... xfwm4]$ Waiting for current window manager (Xfwm4) on screen :0.0 to exit: Done I'll take the new build and try point 1. again. LF
The new build has a small side effect: clicking on maximize, or re scaling the terminal window, does end ./xfwm4 --replace & (so i cannot move it around my desktop) But anyway... I think we might have it. So far, i could not reproduce crashes of xfmw4 (-: But i'll watch it for some days to be sure... LF
(In reply to Linuxfreak from comment #52) > The new build has a small side effect: clicking on maximize, or re scaling > the terminal window, does end ./xfwm4 --replace & (so i cannot move it > around my desktop) I am not sure I understand that part, the trailing ampersand (&) means the program runs in background, so indeed, you will get back to the shell prompt but the program still runs. What if you run it in foreground, without the "&", does it "exit" as well, ie: ./xfwm4 --replace
Created attachment 8493 Normal operation with & Here xwfm4 is called with &. It is waiting for program messages.
No, sorry, you're getting confused here, it is neither waiting for messages nor exiting, this is normal behavior for a program running in background on UNIX/Linux.
Created attachment 8494 Terminal maximized After resizing the terminal or maximizing it, the prompt comes again after "Done". see: [....xfwm4 ]$ Waiting for current window manager (Xfwm4) on screen :0.0 to exit: Done [....xfwm4 ]$ My question is, does the terminal waits also for messages of xwfm4 here, because your last build showed always this: (Done, without a following prompt)? see: [....xfwm4 ]$ After resizing the terminal or maximizing it, the prompt comes again after "Done". (Not that i wait endless for messages that ar not coming here..? )
(In reply to Olivier Fourdan from comment #55) > No, sorry, you're getting confused here, it is neither waiting for messages > nor exiting, this is normal behavior for a program running in background on > UNIX/Linux. Ahh ok, now i got a message (due to resizing, maximizing...): OK so xfwm4 "is" sending messages to the terminal. [ ~]$ cd xfwm4 [... xwm4]$ ./xfwm4 --replace & [1] 1059 [... xfwm4]$ Waiting for current window manager (Xfwm4) on screen :0.0 to exit: Done [... xfwm4]$ (xfwm4:1059): xfwm4-WARNING **: 10:29:25.782: Cannot get window attributes for window (0x4000040) [... xfwm4]$
No, again, you're getting confused here, the new instance of xfwm4 does not exit. By definition, only one window manager can run at at time, so before the new instance of the window manager (xfwm4) can start, it has to tell the previous instance to exit first, this is what the “--replace” is for in the command line. So when you run “./xfwm4 --replace”, it will ask the old instance to exit first, this is what you see in the message "waiting for current window manager to exit: Done". The “Done” here means its “done waiting for the previous window manager to exit”... The shell prompt showing then, again, is perfectly normal for any command being run in background on UNIX/Linux.
Ok thank you. I'am learning always a bit more here. A) So far, locking the screen with the lock-button and unlocking it, at the moment does not lead to a crash. B) Also waiting for the screensaver and the automated lock does not crash after unlocking it again. (I've set the time conditions of https://bugzilla.xfce.org/attachment.cgi?id=8486 to 2, 3 and 4 minutes, to reproduce it faster.) I was working yesterday the whole day at this computer without xfwm4 crashes. But maybe i'll watch this for some more days, to be sure. LF
more of: (xfwm4:1059): xfwm4-WARNING **: 11:19:53.997: Cannot get window attributes for window (0x4027727) (xfwm4:1059): xfwm4-WARNING **: 11:19:54.084: Cannot get window attributes for window (0x4027735)
Those are harmless messages, it can happen if a client window is already gone by the time the window manager tries to manage it.
Is this your version/revisoin? ./xfwm4 --replace [... xfwm4]$ xfwm4 --version This is xfwm4 version 4.13.1git.bb5755 (revision bb5755) for Xfce 4.13 Released under the terms of the GNU General Public License. Compiled against GTK+-3.24.8, using GTK+-3.24.8.
(In reply to Linuxfreak from comment #62) > Is this your version/revisoin? > > ./xfwm4 --replace > [... xfwm4]$ xfwm4 --version > This is xfwm4 version 4.13.1git.bb5755 (revision bb5755) for Xfce 4.13 > Released under the terms of the GNU General Public License. > Compiled against GTK+-3.24.8, using GTK+-3.24.8. No, that version does not contain the fix for this bug.
Closing this bug now, for the record, the fix is commit https://git.xfce.org/xfce/xfwm4/commit/?id=fe9e0f2 Thanks for your help!
(In reply to Olivier Fourdan from comment #64) > Closing this bug now, for the record, the fix is commit > https://git.xfce.org/xfce/xfwm4/commit/?id=fe9e0f2 > > Thanks for your help! Yo! After some testing time, either with lock button, or with auto-screrensaver & autolock,.. the bug did not occur again, after your fix. regards LF