Solved KDE programs core dumps

L

lib13

I'm using 13.0-RELEASE.
Everyday I find some core dumps on my home directory:
Code: 
 42M klauncher.core
 42M drkonqi.core
 42M akonadi_contacts_re.core
 43M plasmashell.core
724M BatteryStatusNo.core
 33G nheko.core

nheko is not part of the default KDE apps.
Still, am I the only one to have this?
 
At least: plasmashell should not crash.

Packages from quarterly, or latest?

Which version of FreeBSD, exactly?

uname -aKU

freebsd-version -kru
 
I'm running quarterly packages.
Code: 
# uname -aKU
FreeBSD leao 13.0-RELEASE-p4 FreeBSD 13.0-RELEASE-p4 #0: Tue Aug 24 07:33:27 UTC 2021     root@amd64-builder.da
emonology.net:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64 1300139 1300139

and

Code: 
# freebsd-version -kru
13.0-RELEASE-p4
 
So your system is up-to-date, but you get core dumps form various packages? In such a case, I would do this:

1. Check your root file system, e.g. fsck / for UFS.
2. Check your memory using sysutils/memtest86
3. Check file /var/log/security or run periodic security as root and look under "Checking for packages with mismatched checksums".

If these steps won't help, you will have to use gdb on these dumps to see what's causing this.
 
More likely than not these programs are crashing on a common denominator - shared library they each depend on. I'd suggest to start with the gdb and see what happened. If you don't have gdb install it. You can check each core file in this manner: gdb -q `which klauncher` ./klauncher.core and in the gdb do:
Code: 
bt
q
Make sure you're using the proper name and core file together. Share the output from these traces.

As an user you can disable creation of such dumps with ulimit -c 0. You can add this into your profile (in bash ~/.bash_profile).
 
This seems only to happen when I poweroff the system.
Next time I power it off, I'll do as suggested.
 
I used to get some of these core dumps, but not all. That was earlier this year, but after recent KDE upgrades they have gone away. Some tweaks of mine, which I've accumulated over the past few years, and which may or may not be helpful still:

1. Uncheck "File search" in System Settings.

2. Add to /etc/fstab:
Code: 
proc            /proc           procfs  rw      0       0
fdesc           /dev/fd         fdescfs rw      0       0
3. Add to /boot/loader.conf:
Code: 
kern.maxfiles="25000"

4. Add to /etc/sysctl.conf:
Code: 
net.local.stream.recvspace=65536
net.local.stream.sendspace=65536

5. Add to /etc/rc.conf:
Code: 
dbus_enable="YES"

6. ~/.xinitrc:
Code: 
exec ck-launch-session dbus-launch --exit-with-session startplasma-x11
 
I think you're supposed to log out of your KDE session before using poweroff, or use the shutdown entry in the main menu instead.
 
bsduck said:
I think you're supposed to log out of your KDE session before using poweroff, or use the shutdown entry in the main menu instead.
Click to expand...

For some types of application, before a graceful shutdown of the OS I always manually quit – and ensure that the quit is complete.

For example: Firefox-related processes may be seen for some time after the application's windows disappear.
 
_martin said:
More likely than not these programs are crashing on a common denominator - shared library they each depend on. I'd suggest to start with the gdb and see what happened. If you don't have gdb install it. You can check each core file in this manner: gdb -q `which klauncher` ./klauncher.core and in the gdb do:
Code: 
bt
q
Make sure you're using the proper name and core file together. Share the output from these traces.

As an user you can disable creation of such dumps with ulimit -c 0. You can add this into your profile (in bash ~/.bash_profile).
Click to expand...
Code: 
$ gdb -q `which klauncher` ./klauncher.core
"/usr/home/lupe/./klauncher.core": not in executable format: file format not recognized 
(gdb) bt 
No stack. 
(gdb) q
 
_martin said:
What does file /usr/home/lupe/./klauncher.core say? Maybe corrupted core file ?
Click to expand...
Code: 
$ file klauncher.core
klauncher.core: ELF 64-bit LSB core file, x86-64, version 1 (FreeBSD), FreeBSD-style, from '/usr/local/lib/libe
xec/kf5/klauncher --fd=8', pid=7112
 
When you use the full path gdb /usr/local/lib/libe xec/kf5/klauncher /usr/home/lupe/klauncher.core ? Does it do the same for other core files? It could be that as it does during shutdown coredump doesn't have time to fully dump itself and those core files are corrupted. At least this what came to my mind when I saw that.
 
If you're using packages, they may have been built with clang.
In that case (of course using full paths as appropriate):
lldb klauncher --core klauncher.core
then
bt and other commands as needed.
 
Ok, with the new suggestions I'm able to output something.

Code: 
$ which klauncher
$ echo $?
1
which doesn't find klauncher


Code: 
$ gdb -q /usr/local/lib/libexec/kf5/klauncher /usr/home/lupe/klauncher.core 
Reading symbols from /usr/local/lib/libexec/kf5/klauncher...
(No debugging symbols found in /usr/local/lib/libexec/kf5/klauncher)
[New LWP 102509]
Core was generated by `/usr/local/lib/libexec/kf5/klauncher --fd=8'.
Program terminated with signal SIGABRT, Aborted.
Sent by thr_kill() from pid 7112 and user 1001.
#0  0x00000008020d82ea in thr_kill () from /lib/libc.so.7
(gdb) bt
#0  0x00000008020d82ea in thr_kill () from /lib/libc.so.7
#1  0x000000080204d064 in raise () from /lib/libc.so.7
#2  0x0000000802101f29 in abort () from /lib/libc.so.7
#3  0x0000000801c658b9 in ?? () from /usr/local/lib/qt5/libQt5Core.so.5
#4  0x0000000801c66f1e in QMessageLogger::fatal(char const*, ...) const ()
   from /usr/local/lib/qt5/libQt5Core.so.5
#5  0x00000008014b39c1 in QGuiApplicationPrivate::createPlatformIntegration() ()
   from /usr/local/lib/qt5/libQt5Gui.so.5
#6  0x00000008014b39f0 in QGuiApplicationPrivate::createEventDispatcher() ()
   from /usr/local/lib/qt5/libQt5Gui.so.5
#7  0x0000000801e3ad47 in QCoreApplicationPrivate::init() () from /usr/local/lib/qt5/libQt5Core.so.5
#8  0x00000008014ad85a in QGuiApplicationPrivate::init() () from /usr/local/lib/qt5/libQt5Gui.so.5
#9  0x00000008014ad802 in QGuiApplication::QGuiApplication(int&, char**, int) ()
   from /usr/local/lib/qt5/libQt5Gui.so.5
#10 0x00000008002582e8 in kdemain () from /usr/local/lib/libkdeinit5_klauncher.so
#11 0x00000000002018c0 in ?? ()
#12 0x00000000002017c0 in ?? ()
#13 0x0000000000000000 in ?? ()
(gdb) q

And for drkonqui:

Code: 
$ gdb -q /usr/local/lib/libexec/drkonqi /usr/home/lupe/drkonqi.core 
Reading symbols from /usr/local/lib/libexec/drkonqi...
(No debugging symbols found in /usr/local/lib/libexec/drkonqi)
[New LWP 101154]
Core was generated by `/usr/local/lib/libexec/drkonqi --appname akonadiserver --apppath /usr/local/bin'.
Program terminated with signal SIGABRT, Aborted.
Sent by thr_kill() from pid 7414 and user 1001.
#0  0x00000008023872ea in thr_kill () from /lib/libc.so.7
(gdb) bt
#0  0x00000008023872ea in thr_kill () from /lib/libc.so.7
#1  0x00000008022fc064 in raise () from /lib/libc.so.7
#2  0x00000008023b0f29 in abort () from /lib/libc.so.7
#3  0x0000000801e658b9 in ?? () from /usr/local/lib/qt5/libQt5Core.so.5
#4  0x0000000801e66f1e in QMessageLogger::fatal(char const*, ...) const ()
   from /usr/local/lib/qt5/libQt5Core.so.5
#5  0x00000008014b39c1 in QGuiApplicationPrivate::createPlatformIntegration() ()
   from /usr/local/lib/qt5/libQt5Gui.so.5
#6  0x00000008014b39f0 in QGuiApplicationPrivate::createEventDispatcher() ()
   from /usr/local/lib/qt5/libQt5Gui.so.5
#7  0x000000080203ad47 in QCoreApplicationPrivate::init() () from /usr/local/lib/qt5/libQt5Core.so.5
#8  0x00000008014ad85a in QGuiApplicationPrivate::init() () from /usr/local/lib/qt5/libQt5Gui.so.5
#9  0x0000000800e962fe in QApplicationPrivate::init() () from /usr/local/lib/qt5/libQt5Widgets.so.5
#10 0x000000000024af48 in ?? ()
#11 0x000000000024ace0 in ?? ()
#12 0x000000000024abe0 in ?? ()
#13 0x0000000000000000 in ?? ()
(gdb) q
 
To me, those backtraces look like what I would expect if you were in KDE and then executed poweroff or something that pulls the rug our from under the system.
SIGABRT is pretty much the "kill yourself" signal and lots of programs may not gracefully exit.
 
So, in FreeBSD either one has to logout from KDE first and then go to a tty and poweroff, or include a shutdown script in order to kill -15 KDE.
Is it like so, then?
 
As mentioned above it seems those processes received abort. Are those two core files you sent traces from the same time? If the abort was sent by the same program or not (different pids are mentioned in those traces).

Have you checked this thread?
 
lib13 said:
… either one has to logout … first and then go to a tty and poweroff, …
Click to expand...

grahamperrin said:
As an operator, a member can (also) benefit from things such as a broader range of options in a log out dialogue, for example:
Click to expand...

– there's a screenshot in the linked post. lib13 please make yourself a member of the operator group.

Vull said:
2. Add to /etc/fstab:

Code: 
proc /proc procfs rw 0 0
fdesc /dev/fd fdescfs rw 0 0
Click to expand...

/proc is no longer required.

I'm not aware of a requirement for fdescfs. Please, where did you learn this?
 
grahamperrin said:
/proc is no longer required.

I'm not aware of a requirement for fdescfs. Please, where did you learn this?
Click to expand...
Forced me to look it up hah! Probably not related; I first noticed it on a recent upgrade. Most likely a libreoffice dependency.

I do remember that the procfs dependency was at one time a KDE/plasma5 dependency, but maybe not anymore. No longer showing up in the pkg messages, but so far it's only hearsay that tells me that it's no longer needed. Better safe than sorry? I don't see where it's hurting anything, and FWIW I'm still not getting any core dumps on a full blown kde install (version 5.22.5_1).

Code: 
Message from openjdk11-11.0.12+7.1:
       
--
This OpenJDK implementation requires fdescfs(5) mounted on /dev/fd and
procfs(5) mounted on /proc.
       
If you have not done it yet, please do the following:
       
        mount -t fdescfs fdesc /dev/fd
        mount -t procfs proc /proc
       
To make it permanent, you need the following lines in /etc/fstab:
       
        fdesc   /dev/fd         fdescfs         rw      0       0
        proc    /proc           procfs          rw      0       0
 
Vull said:
… so far it's only hearsay that tells me that it's no longer needed. …
Click to expand...

The most recent advice was from a reputable source; a FreeBSD developer; a FreeBSD developer. I didn't name the person in the wiki edit because other people in IRC were of the same mind, no dissent.

If you use Matrix and if you were in #freebsd-desktop on 8th October, you'll find part of the conversation at <https://matrix.to/#/!KYWCpFvqYdeGYJ...OdIu6DbLXRePjU?via=libera.chat&via=matrix.org>.
 
Last edited:
You must log in or register to reply here.
Back
Top