Closed Tchou closed 8 months ago
I am getting this same error on my Kubuntu 22.04 LTS system. I have to relaunch the conky each time the configuration is edited as a result.
Okay, I have a new symptom: You can't kill it after editing the config! I mean that even "sudo killall conky-x86_64.appimage" does absolutely nothing. My three conkys will just continue trucking right along like nothing ever happened!? Can't kill them from htop, either! Next time it happens I'll try some things other than rebooting to try and get around this bug.
What makes it even weirder is that sometimes, maybe about 25% of the time at most after editing the config, and almost 100% of the time at boot up (if I don't have a 3 second delay in my loader script), the conkys will load in such a way that clicking on them makes them exit/quit/crash/disappear!? I can then run the exact same loader script from terminal and they will load just fine.
By the way, the appImage conky reports as "AppRun", not "Conky" to the "top cpu/ram"... variables.
Same problem here as well:
conky: '/home/<username>/.conkyrc' modified, reloading...
conky: desktop window (1000006) is subwindow of root window (6d3)
conky: window type - normal
conky: drawing to created window (0x3200002)
conky: drawing to double buffer
/usr/include/c++/13.1.1/bits/stl_vector.h:1125: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](size_type) [with _Tp = x_font_list; _Alloc = std::allocator<x_font_list>; reference = x_font_list&; size_type = long unsigned int]: Assertion '__n < this->size()' failed.
Conky version (--version) info:
conky 1.19.2_pre compiled 2023-05-02 for Linux x86_64
Some OS info, please poke me if you need more information:
Kernel: 6.3.2-zen1-1-zen
Arch: x86_64
Bits: 64
Desktop: MATE
Mate Version: 1.27.0
Distro: Arch Linux
Same here too, also on Arch. No CDE in use. Conky version reported as
conky 1.18.1_pre compiled 2023-02-24 for Linux x86_64
Abort report appears identical to that shown by @panmarco83:
`/usr/include/c++/12.2.1/bits/stl_vector.h:1123: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](size_type) [with _Tp = x_font_list; _Alloc = std::allocator<x_font_list>; reference = x_font_list&; size_type = long unsigned int]: Assertion '__n < this->size()' failed.`
Fwiw: I see that this issue was opened in May, 2023, but am pretty sure its been extant for quite a bit longer than that, dating back to 2022 I think (but not positive of that).
I've had this problem for quite some time, so it is not a recent development.
Cf. #1537 (which is indeed about recent versions of Conky).
Too, conky-1.19.3
/ slackware64-15.0 / openbox-3.6.1
[inst] slackware64 : cairo-1.16.0-x86_64-3
[inst] slackware64 : cairomm-1.12.2-x86_64-4
[inst] slackware64 : fontconfig-2.13.92-x86_64-3
[inst] slackware64 : freetype-2.11.1-x86_64-1
[inst] slackware64 : libXft-2.3.4-x86_64-1
$ conky --version
conky 1.19.3_pre compiled 2023-09-07 for Linux x86_64
Compiled in features:
System config file: /etc/conky/conky.conf
Package library path: /usr/lib64/conky
General:
* math
* hddtemp
* portmon
* IPv6
* Curl
* RSS
* wireless
* support for IBM/Lenovo notebooks
* builtin default configuration
* old configuration syntax
* Imlib2
* OSS mixer support
* apcupsd
* iostats
* ncurses
* Internationalization support
* PulseAudio
Lua bindings:
* Cairo
* Imlib2
X11:
* Xdamage extension
* Xinerama extension (virtual display)
* Xshape extension (click through)
* XDBE (double buffer extension)
* Xft
* ARGB visual
* Own window
* Mouse evenets
Music detection:
* CMUS
* MPD
* MOC
Default values:
* Netdevice: eno1
* Local configfile: $HOME/.conkyrc
* Localedir: /usr/share/locale
* Maximum netdevices: 256
* Maximum text size: 16384
* Size text buffer: 256
Try default config /etc/conky/conky.conf
(in system from data/conky.conf
) stop with Ctrl+C
$ conky -c /etc/conky/conky.conf
conky: desktop window (16b) is root window
conky: window type - desktop
conky: drawing to created window (0x4400001)
conky: drawing to double buffer
^Cconky: received SIGHUP, SIGINT, or SIGTERM to terminate. bye!
conky: fccache.c:807: FcCacheFini: Assertion `fcCacheChains[i] == NULL' failed.
Aborted
try update/stop with killall -SIGUSR1 conky
$ conky -c /etc/conky/conky.conf &
[1] 8377
$ conky: desktop window (16b) is root window
conky: window type - desktop
conky: drawing to created window (0x4400001)
conky: drawing to double buffer
<Enter>
$ killall -SIGUSR1 conky
$ conky: received SIGUSR1. reloading the config file.
conky: fccache.c:807: FcCacheFini: Assertion `fcCacheChains[i] == NULL' failed.
<Enter>
[1]+ Aborted conky -c /etc/conky/conky.conf
try killall conky
$ conky &
[1] 9156
$ conky: desktop window (16b) is root window
conky: window type - desktop
conky: drawing to created window (0x4600001)
conky: drawing to double buffer
<Enter>
$ killall conky
conky: received SIGHUP, SIGINT, or SIGTERM to terminate. bye!
$ conky: fccache.c:807: FcCacheFini: Assertion `fcCacheChains[i] == NULL' failed.
<Enter>
[1]+ Aborted conky
and don't work / Aborted, if editing config.file-conky with started conky -c
, after edited config and save
$ conky -c /tmp/conky.conf
conky: desktop window (16b) is root window
conky: window type - override
conky: drawing to created window (0x4400001)
conky: drawing to double buffer
conky: '/tmp/conky.conf' modified, reloading...
conky: fccache.c:807: FcCacheFini: Assertion `fcCacheChains[i] == NULL' failed.
Aborted
This is up actions works fine w/o aborted on this system with conky-1.15.0
I'm on the same version as @slacknk and it seems to reload on config-file-change-save a few times before it crashes instead of instant crash like it used to be on 1.19.2_pre.
I also downgraded back to Mate desktop 1.26.1-1 since there seems to have been some strange conflict there :confused:
I don't know if the Mate downgrade had any effect or not, but I don't think so since I believe the upgrade of conky and the downgrade of Mate happened at different times entirely.
I'm totally ignorant on a lot of this stuff so I don't know how helpful this will be, but with a bit of research this looks to be an old issue with fontconfig
.
openttd
devs: https://github.com/OpenTTD/OpenTTD/issues/10053, https://github.com/OpenTTD/OpenTTD/pull/10916
This assertion is triggered when fontconfig is deinitialized, while parts of it are still in use. It looks like OpenTTD assumes it's the exclusive user of fontconfig, so this could be triggered if any other shared libraries use fontconfig as well.
Basically, we haven't been a good neighbour. Turns out you shouldn't actually call FcFini when you are done, as some library might still want to use FontConfig. And they use a shared instance for their administration. The idea is that you call FcInit once, and use FcConfigReference / FcDestroyConfig after that to get an instance / release the instance. This entry is ref-counted, and things happen automatically based on that.
svglite
devs: https://github.com/r-lib/svglite/issues/80
The Cairo svg device initialises fontconfig only once per session: https://github.com/wch/r-source/blob/7a39bb9cf2d90571209d82f826976d53faf10bf8/src/library/grDevices/src/cairo/cairoFns.c#L678 and doesn't finalise it. Maybe it does not clean up other related resources correctly and this triggers the crash when we try to finalise fontconfig in gdtools. Quick solution: not finalising fontconfig in gdtools to be on the safe side.
xpdfreader
devs: https://forum.xpdfreader.com/viewtopic.php?t=41895
I don't quite understand the cause of the crash, but it seems to be a disagreement between libraries when it comes to cleaning up memory usage by calling the FcFini fontconfig function. chromium, abiword and other apps, as I understand, have simply worked around this by not calling FcFini and living with the leaks.
chromium
devs: https://bugs.chromium.org/p/chromium/issues/detail?id=32091
The fontconfig code was updated to check that fontconfig is correctly shut down on FcFini(). However, pango still refuses to to free all fontconfig resources. I guess the only solution is to not shut down fontconfig and live with the (bigger) leaks.
gargoyle
devs:
Based on some investigation of the error message online, it looks like it is caused somehow via a call in garglk/fontfc.cpp:
void fontunload() { if (initialized) { FcFini(); // <-- here } }
If changed to
void fontunload() { if (false) { // disabled FcFini(); } }
then the problem does not occur after a rebuild, but this doesn’t seem like the proper solution.
Potentially an easy fix?
I saw a handful of workarounds that allegedly solved the issue by removing uninstalled font folders with only .uuid files inside in /usr/share/fonts/, but I could not corroborate this.
I have this problem too.
conky --version
conky 1.19.3_pre compiled 2023-10-15 for Linux x86_64
Compiled in features:
System config file: /etc/conky/conky.conf
Package library path: /usr/lib64/conky
General:
* math
* hddtemp
* portmon
* IPv6
* Curl
* RSS
* wireless
* support for IBM/Lenovo notebooks
* nvidia
* builtin default configuration
* old configuration syntax
* Imlib2
* OSS mixer support
* apcupsd
* iostats
* ncurses
* Internationalization support
* PulseAudio
* Debugging extensions
Lua bindings:
* Cairo
* Imlib2
X11:
* Xdamage extension
* Xinerama extension (virtual display)
* Xshape extension (click through)
* XDBE (double buffer extension)
* Xft
* ARGB visual
* Own window
* Mouse evenets
Music detection:
* Audacious
* CMUS
* MPD
* MOC
Default values:
* Netdevice: eno1
* Local configfile: $HOME/.conkyrc
* Localedir: /usr/share/locale
* Maximum netdevices: 256
* Maximum text size: 16384
* Size text buffer: 256
tell me what to debug.
I know that Conky's maintainers are not exactly obligated to fix any bug, but this bug is a regression and a really irritating one. So: it seems bad, and it looks bad, and it is an inconvenience to users of this marvellous software, that Conky's developers seem not to care about this bug. Please fix it or at least try to fix it or at least explain what the problem is.
In case no one noticed it seems that the bug was fixed by: https://github.com/brndnmtthws/conky/pull/1606
which is included in conky 1.19.4
I can now reliably send SIGUSR1
or update .conkyrc without conky crashing (I have only tested with conky 1.19.6 though, but I'm sure this is the PR that fixed this particular bug).
@Tchou: Thanks for mentioning this. Can confirm fixed in 1.19.6 (built from sources) on my Arch setup also. So maybe @brndnmtthws can close it now, if others concur.
Interestingly though, Arch has not updated conky in their core repo for a long time. They presently have 1.18.1-2 in there, which has been flagged as "out of date" since March, 2023.
Anyway... h/t to devs for getting this fixed.
In case it matters, I have tested this both from a Wayland session and from a pure X11 session (using Ubuntu+Gnome 45 meaning mutter as a compositor/display manager/window manager) and in both cases conky reloads reliably after receiving a signal.
1) It would have been good to here from a Conky dev that the bug was fixed.
2) Just now, I built from source (v. 1.19.6_pre) and the bug seems to persist (on Linux Mint Cinnamon 21.2, which is based upon Ubuntu 22.02). Still, my build script does reflect my limited git ability, so it is possible that somehow I have failed to fetch the latest stuff. I say that the bug seems to persist because when I save a change to my conkyrc file, I get:
conky: '</path/to/my/conkyrc>' modified, reloading...
conky: fccache.c:795: FcCacheFini: Assertion `fcCacheChains[i] == NULL' failed.
. . and Conky crashes.
EDITED (to fix minor things).
@LinuxOnTheDesktop
Same bug here in Linux Mint Xfce 21.3 with conky 1.19.7_pre compiled 2024-02-09 for Linux x86_64
I can confirm what @jakariyaa and @LinuxOnTheDesktop said that this bug is not resolved in Conky 1.19.6 as reported by @Tchou and @ahmogit.
I tested Conky 1.19.6 compiled yesterday on my Debian 10 system. It has kernel (version 6.1.0-18-amd64) and few firmware packages from Debian 12 and also has some backported and local packages. But from the packages used for Conky build only "cmake", "cmake-data", "debhelper" and "dwz" were used from Debian 10 Backports while the other Conky build dependencies were from Debian 10 Main repositories. I wanted Conky with only the features I need, so I set the following build flags:
CMAKE_C_FLAGS="$(DEB_CFLAGS) $(DEB_CPPFLAGS)" CMAKE_CXX_FLAGS="$(DEB_CXXFLAGS) $(DEB_CPPFLAGS)"
CMAKE_BUILD_TYPE=Release CMAKE_INSTALL_PREFIX=/usr RELEASE=True
BUILD_APCUPSD=OFF
BUILD_ARGB=ON
BUILD_AUDACIOUS=OFF
BUILD_BUILTIN_CONFIG=OFF
BUILD_CMUS=OFF
BUILD_CURL=OFF
BUILD_DOCS=OFF
BUILD_EXTRAS=OFF
BUILD_HDDTEMP=OFF
BUILD_HTTP=OFF
BUILD_I18N=OFF
BUILD_IBM=OFF
BUILD_ICAL=OFF
BUILD_ICONV=OFF
BUILD_IMLIB2=ON
BUILD_INTEL_BACKLIGHT=OFF
BUILD_IOSTATS=ON
BUILD_IPV6=OFF
BUILD_IRC=OFF
BUILD_JOURNAL=OFF
BUILD_LUA_CAIRO=OFF
BUILD_LUA_IMLIB2=OFF
BUILD_LUA_RSVG=OFF
BUILD_MATH=ON
BUILD_MOC=OFF
BUILD_MOUSE_EVENTS=OFF
BUILD_MPD=OFF
BUILD_MYSQL=OFF
BUILD_NCURSES=OFF
BUILD_NVIDIA=OFF
BUILD_OLD_CONFIG=OFF
BUILD_PORT_MONITORS=ON
BUILD_PULSEAUDIO=OFF
BUILD_RSS=OFF
BUILD_WAYLAND=OFF
BUILD_WLAN=ON
BUILD_X11=ON
BUILD_XDAMAGE=ON
BUILD_XDBE=ON
BUILD_XFIXES=ON
BUILD_XFT=ON
BUILD_XINERAMA=OFF
BUILD_XMMS2=OFF
BUILD_XSHAPE=ON
The "DEB_C*FLAGS" variables had the following values:
DEB_CFLAGS = DEB_CXXFLAGS = -g -O2 -fdebug-prefix-map=/CONKY/BUILD/DIRECTORY=.
-fstack-protector-strong -Wformat -Werror=format-security
DEB_CPPFLAGS = -Wdate-time -D_FORTIFY_SOURCE=2
The result is that Conky crashes on any config modification when use_xft = true
is in my config:
STARTING CONKY 1.19.6 WITH "use_xft = false" IN MY CONFIG:
PC:~$ conky --config=/etc/conky.rc
conky: desktop window (a00003) is subwindow of root window (182)
conky: window type - normal
conky: drawing to created window (0x2c00002)
conky: drawing to double buffer
conky: forked to background, pid is 6000
conky: can't load font 'Liberation Mono:size=10'
conky: can't load font 'Liberation Mono:size=10'
SAVED MY CONFIG AGAIN (WITH NO CHANGES JUST TO FORCE RELOAD):
conky: '/etc/conky.rc' modified, reloading...
conky: desktop window (a00003) is subwindow of root window (182)
conky: window type - normal
conky: drawing to created window (0x2c00002)
conky: drawing to double buffer
conky: can't load font 'Liberation Mono:size=10'
conky: can't load font 'Liberation Mono:size=10'
SAVED MY CONFIG WITH "use_xft = true" IN MY CONFIG:
conky: '/etc/conky.rc' modified, reloading...
conky: desktop window (a00003) is subwindow of root window (182)
conky: window type - normal
conky: drawing to created window (0x2c00002)
conky: drawing to double buffer
SAVED MY CONFIG AGAIN (WITH NO CHANGES JUST TO FORCE RELOAD):
conky: '/etc/conky.rc' modified, reloading...
conky: fccache.c:795: FcCacheFini: Assertion `fcCacheChains[i] == NULL' failed.
CONKY CRASHED, ITS PROCESS DISAPPEARED FROM HTOP.
The result is also that Conky crashes (when use_xft = true
is in my config) when Xrandr changes the screen layout triggering SIGUSR1 received by Conky:
STARTING CONKY 1.19.6 WITH "use_xft = true" IN MY CONFIG:
PC:~$ conky --config=/etc/conky.rc
conky: desktop window (a00003) is subwindow of root window (182)
conky: window type - normal
conky: drawing to created window (0x2400002)
conky: drawing to double buffer
conky: forked to background, pid is 1105
USED MY SCRIPT THAT SWITCHES DISPLAYS BETWEEN EXTENDED AND MIRROR MODE USING XRANDR:
conky: received SIGUSR1. reloading the config file.
conky: fccache.c:795: FcCacheFini: Assertion `fcCacheChains[i] == NULL' failed.
CONKY CRASHED, ITS PROCESS DISAPPEARED FROM HTOP.
So the bug really occurs for me on any config reload (when use_xft = true
is in my config). I could live with Conky not surviving modified config reload (as I change config only when I need to), but my script adjusts the screen layout via Xrandr after each XFCE (re)start/(re)login and that crashes all my Conky instances.
Without use_xft = true
in my config the font is not loaded and text is more difficult to read and looks ugly. I can manually (re)start my Conky instances and could automate that. But SIGUSR1 after Xrandr switched displays to the extended mode (external LCD on top + laptop LCD under it) has the effect of Conky keeping its position on laptop LCD without the need to change the "gap_x" or "gap_y" in Conky config. Thus my configs with "gap_x" and "gap_y" values for the single laptop LCD worked also with external LCD/projector setups. All without any complicated mechanisms for changing "gap_x" and "gap_y" values in Conky configs according to the current screen layout.
If I cannot resolve these crashes this will stop my upgrade from Conky 1.10.8 (which I need to move away from execi
overuse:). So has anyone found any good workaround? Or should I comment out the FcFini
call in display-x11.cc
and live with a potential memory leak? Would making SIGUSR1 not trigger the config reload be a better possible workaround for me or would it cause other more severe problems?
@Jmkrnet All I can say is that the version that I built locally from 1.19.6_pre sources definitely fixes the restart-crash issue on my setup. I checked again, just now, to be sure that I hadn't somehow misinterpreted or mis-reported the results that I mentioned earlier, but the behavior that I see on my system is that conky restarts successfully upon modification to .conkyrc.
I have little expertise in the font config stuff that seems to be at the core of this issue, but if I can be of help in tracking down what might be key differences between your (@jmkrnet) system and mine, glad to assist if I can. Just let me know what would be useful for you to see, I'll post it.
Fwiw, the output from "conky --version" of my executable is attached. Not sure it will shed any light, but perhaps.
@ahmogit On my system packages fontconfig
, fontconfig-config
and libfontconfig1
are at version 2.13.1-2 from Debian 10 Main repository. Which version of Fontconfig is on your system?
In the meantime I analyzed the Fontconfig source code and focused on the FcFini()
function:
The FcFini()
source code is nearly the same for Fontconfig 2.13.1 tag and Main branch - it calls the following 5 functions: FcConfigFini()
, FcConfigPathFini()
, FcDefaultFini()
, FcObjectFini()
, and FcCacheFini()
. Only the order is different in Fontconfig 2.13.1 tag FcCacheFini()
is 2nd and FcConfigPathFini()
last.
The FcConfigFini()
source code is the same for Fontconfig 2.13.1 tag and Main branch with the exception of one extra last line free_lock ();
in Main branch.
The FcConfigPathFini()
source code is the same for Fontconfig 2.13.1 tag and Main branch.
The FcDefaultFini()
source code is the same for Fontconfig 2.13.1 tag and Main branch with the exception of few extra last lines in Main branch:
desktop = fc_atomic_ptr_get (&default_desktop_name);
if (desktop && fc_atomic_ptr_cmpexch(&default_desktop_name, desktop, NULL))
{
free (desktop);
}
and the one extra variable declaration FcChar8 *desktop;
on line 4 in Main branch.
The FcObjectFini()
source code is the same for Fontconfig 2.13.1 tag and Main branch.
The FcCacheFini()
source code change between Fontconfig 2.13.1 tag and Main branch could be the significant difference that causes the bug on my system. The following 3 lines in Fontconfig 2.13.1 tag:
for (i = 0; i < FC_CACHE_MAX_LEVEL; i++)
assert (fcCacheChains[i] == NULL);
assert (fcCacheMaxLevel == 0);
were replaced by 11 lines in Main branch:
if (FcDebug() & FC_DBG_CACHE)
{
for (i = 0; i < FC_CACHE_MAX_LEVEL; i++)
{
if (fcCacheChains[i] != NULL)
{
FcCacheSkip *s = fcCacheChains[i];
fprintf(stderr, "Fontconfig error: not freed %p (dir: %s, refcount %" FC_ATOMIC_INT_FORMAT ")\n", s->cache, FcCacheDir(s->cache), s->ref.count);
}
}
}
The FcCacheFini()
changes happened in the following 2 commits:
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/commit/6f6b39780215714386606ca1c5457a7106639ff4
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/commit/92f093a4c493dc93958ef750a6d66ad9b1ad68d4
The 2nd commit completely replaced the assertion that causes the error message on my system and the whole reporting source code should only run when debugging with FC_DEBUG=16
. So I will probably try to rebuild Fontconfig packages from Debian 12 for my system and see if that solves the bug for me. I will report back when I have some results:).
@Jmkrnet Presently, my system reports fontconfig version as 2:2.15.0-2.
Hasn't had 2.13.x since April 2022
Attached is the update history of fontconfig on my system, going back to 2020.
@ahmogit Thanks for your quick comments and Fontconfig versions report. When I saw the keywords "font config stuff" in your comment it forced me to re-read the beginning of this bug report. After I examined the Fontconfig sources @Tchou mentioned, I found myself on the right track.
Now I can report that you were both right = Conky 1.19.6 really does not crash on reload with use_xft = true
in my config. But one needs also a recent enough version of Fontconfig installed that probably includes the 2nd commit I mentioned:
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/commit/92f093a4c493dc93958ef750a6d66ad9b1ad68d4
I built the Fontconfig 2.15.0-1 from Debian Sid (Unstable) repositories for my Debian 10 system. I also had to upgrade "autoconf", "automake" and "autotools-dev" packages to their Debian 12 versions to avoid some build errors. So @jakariyaa and @LinuxOnTheDesktop can try to upgrade their Fontconfig versions and see if it helps them. Probably the bug can be also closed now as Conky devs see fit.
My thanks to everyone who is sharing tips within this thread.
@Jmkrnet: would you supply a link to the FontConfig source code that you mention?
Here is why I ask. I am on Linux Mint. So I tried to find a suitable Ubuntu .deb, and I did, or at least a fairly recent deb of FontConfig, but I seemed stuck in dependency hell. Then I sought and found Debian .debs, but I didn't get anywhere with them either - and Firefox kept warning me about insecure downloads. So building from source does seem to be the way. I take it from you (Jmkrnet) that so doing will involve updating some tooling (but the Ubuntu-deb route itself seemed to need a new libc . .).
Finally: I notice that Conky 1.19.7 has arrived just now; but its changelog does not suggest (unless I am mistaken) that it will solve the reload problem.
@LinuxOnTheDesktop I think you need Conky 1.19.6+ and Fontconfig 2.15.0+. See the "Tags containing commit" link in this page with the relevant Fontconfig commit I mentioned in previous message: https://gitlab.freedesktop.org/fontconfig/fontconfig/-/commit/92f093a4c493dc93958ef750a6d66ad9b1ad68d4
Not sure how recent Fontconfig packages are in your Linux Mint repository, but probably you will need to rebuild at least Fontconfig. Maybe you can try just rebuilding Fontconfig DEB packages from Debian Sid source package. After you download and extract the source package and install its build dependencies you can try to use dpkg-buildpackage
and hope that Mint is similar enough to Debian (run from the extracted source package directory):
DEB_BUILD_OPTIONS='nocheck nodoc' DEB_BUILD_PROFILES="$DEB_BUILD_OPTIONS" dpkg-buildpackage --build=binary --unsigned-changes
If you have enabled Debian Sid Source repository in your "/etc/apt/sources.list" (e.g. add line like: deb-src http://deb.debian.org/debian/ unstable main
and update with apt-get update
) you can try to download the source package and its dependencies with apt-get
(otherwise download from "https://packages.debian.org/source/sid/fontconfig" and install dependencies manually with your package manager):
apt-get source --download-only --only-source fontconfig/sid
apt-get build-dep --only-source fontconfig/sid
Installed build dependencies and added "deb-src" repository can be removed after building - you do not need these to install and use the generated DEB packages. I can also recommend testing generated DEB packages first in Virtual Machine just to be on the safe side:).
This should be resolved with https://github.com/brndnmtthws/conky/pull/1755.
@brndnmtthws : I tested the putative fix/workaround and it does seem to work. Great! Yet, given the valgrind warning, perhaps it would be good to revert the change once Fontconfig >=2.15.0 is in wider circulation.
@ Jmkrnet : thank you very much - that was most considerate of you - though I fear that your kind effort is now superseded!
What happened?
Conky crashes with the message:
when restarting after .conkyrc is modified. Recompiling with debug and getting a backtrace in gdb gives:
The culprit is the call to
FcFini
indisplay-x11.cc
, commenting this call restores the correct behavior (not crashing on reload). After further research, I stumbled upon this fontconfig issue which seems relevant here. Unfortunately, it seems that removing the call toFcFini
may leak some memory, but there does not seem to be a way to properly clean Xft's internal structures.Version
1.91.1, 1.19.2, main
Which OS/distro are you seeing the problem on?
Ubuntu
Conky config
conky
crashes on reload.