| View previous topic :: View next topic |
| Author |
Message |
Tout
n00b
Joined: 18 Jul 2020
Posts: 46
|
 Posted: Fri Oct 11, 2024 11:34 am Post subject: New version Conky segfault at boot using Gnome |
 |
|
Hi!
After updating conky, I noticed that conky is not starting at boot anymore. When looking at syslog, I see a segfault is occuring.
I have two instances of conky starting at boot. So for 3 boots I got this:
| Code: | Oct 11 10:23:50 main kernel: conky[3708]: segfault at 10 ip 00007f389c981424 sp 00007ffd490c8cd8 error 4 in libc.so.6[7f389c916000+148000] likely on CPU 5 (core 5, socket 0)
Oct 11 10:23:50 main kernel: conky[3698]: segfault at 10 ip 00007f980905f424 sp 00007ffe62afc248 error 4 in libc.so.6[7f9808ff4000+148000] likely on CPU 10 (core 2, socket 0)
Oct 11 10:57:03 main kernel: conky[3679]: segfault at 10 ip 00007fd5c871b424 sp 00007fff3cfd83d8 error 4 in libc.so.6[7fd5c86b0000+148000] likely on CPU 6 (core 6, socket 0)
Oct 11 10:57:04 main kernel: conky[3669]: segfault at 10 ip 00007f8d89f05424 sp 00007ffd23630158 error 4 in libc.so.6[7f8d89e9a000+148000] likely on CPU 10 (core 2, socket 0)
Oct 11 11:16:44 main kernel: conky[4769]: segfault at 10 ip 00007f0f3a23e424 sp 00007ffd65640ed8 error 4 in libc.so.6[7f0f3a1d3000+148000] likely on CPU 4 (core 4, socket 0)
Oct 11 11:16:44 main kernel: conky[4762]: segfault at 10 ip 00007f1715727424 sp 00007ffe6fb446f8 error 4 in libc.so.6[7f17156bc000+148000] likely on CPU 0 (core 0, socket 0)
|
Reverting to the old version of conky, it does not occur.
New version being: 1.21.7
Old version is: 1.19.8
When using the new version, I do not get any error when starting it AFTER boot. No segfaults occurring.
I use gnome and autostart conky with an autostart config. Trying to add a delay did not work, cause I don't know how to configure that correctly. The internet is giving me spread info on if that is still working in gnome autostart.
| Code: | ~/.config/autostart $ cat conky.desktop
[Desktop Entry]
Type=Application
Name=Conky
Exec=conky
X-GNOME-Autostart-Delay=120 |
Two questions:
1) Can I further investigate what is going wrong besides the syslog entry?
2) Is there a correct way of delaying in autostart? My current workaround is masking the new version. There could be an alternative workaround to delay start, but not sure if it will help. It might, because starting conky from prompt works once system is running.
Any help appreciated. |
|
| Back to top |
|
 |
Weezer
n00b
Joined: 19 Apr 2024
Posts: 22
|
| Posted: Sun Oct 13, 2024 9:25 am Post subject: Re: New version Conky segfault at boot using Gnome |
|
|
| Tout wrote: |
2) Is there a correct way of delaying in autostart? My current workaround is masking the new version. There could be an alternative workaround to delay start, but not sure if it will help. It might, because starting conky from prompt works once system is running.
|
I don't use Gnome, but I would try nuking the XDG-GNOME-Autostart-Delay line in the .desktop file and doiing something like:
Exec=sleep 120 && conky
or if that is the wrong context try;
Exec=bash -c "sleep 120 && conky"
I doubt you need a two minute delay but you can whittle that down after you get it working.
I autostart my conky and do it a bit different but this should work (untested as I use window managers), or get you going in the right direction.
 |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22504
|
| Posted: Sun Oct 13, 2024 2:50 pm Post subject: |
|
|
| Can you obtain a core file for the faulting conky? Can you find a way to reproduce it that does not require a reboot for every attempt? |
|
| Back to top |
|
|
Tout
n00b
Joined: 18 Jul 2020
Posts: 46
|
| Posted: Sun Oct 13, 2024 7:06 pm Post subject: Re: New version Conky segfault at boot using Gnome |
|
|
| Quote: | I don't use Gnome, but I would try nuking the XDG-GNOME-Autostart-Delay line in the .desktop file and doiing something like:
Exec=sleep 120 && conky
or if that is the wrong context try;
Exec=bash -c "sleep 120 && conky"
I doubt you need a two minute delay but you can whittle that down after you get it working.
I autostart my conky and do it a bit different but this should work (untested as I use window managers), or get you going in the right direction.
|
Yes!! The Exec=bash -c "sleep 60 && conky" worked. Not the first one. I guess it needs to be ran in the same bash command.
So very nice, I have a work around running the latest version. Now I can research further for the root cause. Thanks!! |
|
| Back to top |
|
|
Tout
n00b
Joined: 18 Jul 2020
Posts: 46
|
| Posted: Sun Oct 13, 2024 7:31 pm Post subject: |
|
|
| Hu wrote: | | Can you obtain a core file for the faulting conky? Can you find a way to reproduce it that does not require a reboot for every attempt? |
I can't get conky to segfault after gnome is up and running. For example the work around with the delay makes conky run correctly without segfault.
Is there a way to debug more? The only thing where I look now is syslog. There I can find a few surrounding lines:
| Code: | Oct 13 21:19:34 main dbus-daemon[1323]: [system] Successfully activated service 'org.freedesktop.UDisks2'
Oct 13 19:19:34 main rtkit-daemon[2407]: Successfully made thread 3012 of process 3012 owned by '1000' high priority at nice level -11.
Oct 13 19:19:34 main rtkit-daemon[2407]: Successfully made thread 3017 of process 3012 owned by '1000' RT at priority 20.
Oct 13 19:19:35 main rtkit-daemon[2407]: Successfully made thread 2955 of process 2955 owned by '1000' high priority at nice level -11.
Oct 13 19:19:35 main rtkit-daemon[2407]: Successfully made thread 3041 of process 2955 owned by '1000' RT at priority 20.
Oct 13 21:19:35 main kernel: [drm:drm_new_set_master] *ERROR* [nvidia-drm] [GPU ID 0x00000800] Failed to grab modeset ownership <not related>
Oct 13 21:19:37 main kernel: conky[2974]: segfault at 10 ip 00007f8c5403f424 sp 00007ffcaa096028 error 4 in libc.so.6[7f8c53fd4000+148000] likely on CPU 4 (core 4, socket 0)
Oct 13 21:19:37 main kernel: Code: <a lot of hex numbers here, which I stripped, cause I do not know if they identify anything>
Oct 13 21:19:37 main NetworkManager[1635]: <info> [<I deleted info here>] agent-manager: agent[<I deleted info here>/org.gnome.Shell.NetworkAgent/1000]: agent registered
|
Where I can see my rtkit-daemon likes to travel back in time. But I think that should be ok, cause it seems to use UTC, and if I was a rtkit-daemon I would do the same.
Then I also see this nvidia-drm error, which seems to can occur. But does not seem related, cause the old version of conky works?
edit: I got rid of this by adding (so it is definitely not related)
| Code: | | nvidia-drm.modeset=1 nvidia-drm.fbdev=1 |
to the GRUB_CMDLINE_LINUX_DEFAULT= to my grub config
And finally after the segfault a related line I guess with some code of the kernel. Where I removed the hex numbers because I am too paranoid to put them here without knowing what it translates into. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22504
|
| Posted: Sun Oct 13, 2024 7:46 pm Post subject: |
|
|
| If it only crashes at startup, then obtaining a core file from a crash at startup, and diagnosing it later, would be the most expedient path. |
|
| Back to top |
|
|
Tout
n00b
Joined: 18 Jul 2020
Posts: 46
|
| Posted: Sun Oct 13, 2024 8:00 pm Post subject: |
|
|
| Hu wrote: | | If it only crashes at startup, then obtaining a core file from a crash at startup, and diagnosing it later, would be the most expedient path. |
Thanks!! I managed a core dump by adding:
| Code: | | Exec=bash -c "ulimit -c unlimited && conky" |
I will now investigate how to read the core dump. |
|
| Back to top |
|
|
Tout
n00b
Joined: 18 Jul 2020
Posts: 46
|
| Posted: Sun Oct 13, 2024 8:13 pm Post subject: |
|
|
Debugging the core dump by:
| Code: | | gdb /usr/bin/conky core |
And printing the backtrace gives:
| Code: | (gdb) bt
#0 0x00007f57caab0424 in pthread_mutex_lock () at /lib64/libc.so.6
#1 0x00007f57cb2f589f in XrmQGetResource () at /usr/lib64/libX11.so.6
#2 0x00007f57cb2f5a0d in XrmGetResource () at /usr/lib64/libX11.so.6
#3 0x0000563533c822ed in ??? ()
#4 0x0000563533c85a1b in ??? ()
#5 0x0000563533c85b67 in ??? ()
#6 0x0000563533c35a1b in ??? ()
#7 0x0000563533c1e8c1 in main () |
At least I am learning things again
So I guess the function XrmGetResource calls XrmQGetResource which calls pthread_mutex_lock. And that last one gives the segfault?
Edit: yes, the first lines when starting gdb say so:
| Code: | Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f57caab0424 in pthread_mutex_lock () from /lib64/libc.so.6
[Current thread is 1 (Thread 0x7f57ca01e940 (LWP 2950))] |
So question is, what is my next step?
edit: I tried using vgdb which seems to be very nice, but since it occurs only during boot, not an option I guess |
|
| Back to top |
|
|
|
Portage & Programming
