SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
quick comment, it's not _Krusader_, but _solid_ that needs to be rebuilt.
Furthermore, it's not yet enough to get meaningful data.
I'll try to come back with more details soon enough.
Oops. In that case, it might be as simple as doing the above cmake edits, but with solid instead, editing the solid build number from 1 to 2, and running kde.SlackBuild frameworks:solid.
I believe the gdb information would still be accurate other than probably needing to specify the actual location of the krusader binary (I'll edit my previous comment).
However, hopefully Andrzej can come back with more details to be able to submit a better bug report to the KDE devs.
We still don't know about possibility that bug influence only Slackware. Because of custom settings. I mean common reason tells that it is not possible for KDE developers to omit this bug - if is generic. I mean almost everyone KDE user should witness something like that.
It will be good to catch the source of NULL value in strcmp call. For me it seems that from point of view of KDE developers such situation is just not possible. I got some short look at /proc/self - not easy to understand the purpose of this.
As I understand that part of code does system call which populate /proc/self. I found that this is how df works for example. Now imagine that df instead of mounts returns NULL. Precisely what I understood is that df gains information about mounts through "looking at" /proc/self/mountinfo.
Common sense tells you that correct call to "look at" /proc/self/mountinfo cannot return NULL. It is like process would live in empty space without no mounts at all! Even not root /. That's absurd.
My conclusion: there must be another issue. Let don't haste with this patch. Perhaps it is not wrongdoing of KDE developers.
Edit: You can do fancy thing and compare outputs of
We still don't know about possibility that bug influence only Slackware. Because of custom settings. I mean common reason tells that it is not possible for KDE developers to omit this bug - if is generic. I mean almost everyone KDE user should witness something like that.
It will be good to catch the source of NULL value in strcmp call. For me it seems that from point of view of KDE developers such situation is just not possible. I got some short look at /proc/self - not easy to understand the purpose of this.
As I understand that part of code does system call which populate /proc/self. I found that this is how df works for example. Now imagine that df instead of mounts returns NULL. Precisely what I understood is that df gains information about mounts through "looking at" /proc/self/mountinfo.
Common sense tells you that correct call to "look at" /proc/self/mountinfo cannot return NULL. It is like process would live in empty space without no mounts at all! Even not root /. That's absurd.
Man, you are kind to stop with those Plasma5 settings?
They cannot have a role there, because the way the things works has nothing to do with the user settings.
From what my friend said - i asked him about, it's about using the libmount functions (which library is shipped util-linux) to parse /proc/self/mountinfo. It's that low level.
Quote:
Originally Posted by igadoter
My conclusion: there must be another issue.
Yeah, there certainly IT IS an issue: apparently, our libmount parsing of /proc/self/mountinfo is in a way which sometimes makes mnt_fs_get_root() to return NULL.
Quote:
Originally Posted by igadoter
Let don't haste with this patch. Perhaps it is not wrongdoing of KDE developers.
My friend said that the KDE developers DID IT wrong - not by writing wrong code, BUT rather by omitting a certain safety check.
So, they passed the output of a function which MAY return NULL, mnt_fs_get_root() directly as parameter for a function which DOES NOT accept it to be NULL on the current usage: strcmp()
The proposed patch just this do: adds a safety check for the case WHEN from whatever reason, mnt_fs_get_root() returns NULL.
The real life demonstrated that this mnt_fs_get_root() may return NULL, even the KDE developers supposed that this will not happen.
This is the single reason WHY this patch fix the behavior for the users affected by this issue.
Last edited by LuckyCyborg; 07-21-2021 at 01:58 PM.
Did you notice my post about libmount? As for me it is main suspect now.
There are used ONLY functions from libmount, and they DO some safety checks. I will show you in red the lines with them:
Code:
static QString baseMountPoint(const QByteArray &dev)
{
QString mountPoint;
#if HAVE_LIBMOUNT
// UDisks "MountPoints" property contains multiple paths, this happens with
// devices with bind mounts; try finding the "base" mount point
if (struct libmnt_table *table = mnt_new_table()) {
// This parses "/proc/self/mountinfo" by default
if (mnt_table_parse_mtab(table, nullptr) == 0) {
// BACKWARD because the fs's we're interested in, /dev/sdXY, are typically at the end
struct libmnt_iter *itr = mnt_new_iter(MNT_ITER_BACKWARD);
struct libmnt_fs *fs;
const QByteArray devicePath = dev.endsWith('\x00') ? dev.chopped(1) : dev;
while (mnt_table_next_fs(table, itr, &fs) == 0) {
if (mnt_fs_get_srcpath(fs) == devicePath
// Base mount point will have "/" as root fs
&& (strcmp(mnt_fs_get_root(fs), "/") == 0)) { // <------- HERE CRASHES!
mountPoint = QFile::decodeName(mnt_fs_get_target(fs));
break;
}
}
mnt_free_iter(itr);
}
mnt_free_table(table);
}
#endif
return mountPoint;
}
The both IFs in red are safety checks.
WHY they did NOT checked also the output of mnt_fs_get_root() for containing a valid string, i.e. not NULL ? Because this NULL will never happen?
Last edited by LuckyCyborg; 07-21-2021 at 02:09 PM.
However, hopefully Andrzej can come back with more details to be able to submit a better bug report to the KDE devs.
1. In _kde.options_ in _SLKCFLAGS_ **matching your arch** replace _-O2_ with:
Code:
-Og
and add:
Code:
-ggdb3
so for example, for **x86_64**, it becomes:
Code:
export SLKCFLAGS="-ggdb3 -Og -fPIC"
2. In _cmake/solid_ replace _-DCMAKE_BUILD_TYPE=Release_ with:
Code:
-DCMAKE_BUILD_TYPE=debugfull
(_-DCMAKE_BUILD_TYPE=Debug_ might work, but Arch suggests _debugfull_ and I didn't test which is better or correct)
3. Prevent stripping of binaries:
Code:
$ touch nostrip/solid
4. Prevent removing source code after building:
Code:
$ CLEANUP=no ./kde.SlackBuild frameworks:solid
5. One can use _nm_ to see whether the debugging symbols are present in a shared library:
Code:
# Example with no symbols:
$ nm /usr/lib64/libgit2.so
nm: /usr/lib64/libgit2.so: no symbols
# Example with symbols present in the library:
$ nm /usr/lib64/libKF5Solid.so.5 | head
000000000003a61a t PredicateLexer_unknownToken
000000000003a800 t PredicateParse_appendStringListValue
0000000000039e8b t PredicateParse_destroy
000000000003a8e4 t PredicateParse_errorDetected
0000000000047745 t PredicateParse_initLexer
000000000004682c t PredicateParse_mainParse
000000000003a282 t PredicateParse_newAnd
0000000000039f3d t PredicateParse_newAtom
000000000003a593 t PredicateParse_newBoolValue
000000000003a5eb t PredicateParse_newDoubleValue
As a funny fact, _mc_ or rather _mcedit_ can show _kinda_ similar details when one tries to open an executable or library file for _editing_.
It may have been mentioned earlier but here's my experience regarding the Plasma crash when trying to mount a partition (a USB key in my case) in dolphin.
I have at the moment two Slackware64 current partitions on the same machine (one will stay current while the other will follow 15.0 in case you wonder). I have updated both current systems to "Wed Jul 21 05:30:44 UTC 2021" except for the kernel:
- On current #1 with kernel 5.12.15 : no crash. I can mount USB key in dolphin (even with solid 5.84)
- On current #2 with kernel 5.13.4 : crash when trying to mount USB key
Are you sure Solid should be linked against libmount? The only call for libmount on my system is in libKF5WebKit.so. Ok let me state this in different way. Which library/programs links to libmount? I am not specialist. I used ldd to find guilty guy due to #IF_HAVE_LIBMOUNT. And libKF5WebKit.so is only one.
Are you sure Solid should be linked against libmount? The only call for libmount on my system is in libKF5WebKit.so. Ok let me state this in different way. Which library/programs links to libmount? I am not specialist. I used ldd to find guilty guy due to #IF_HAVE_LIBMOUNT. And libKF5WebKit.so is only one.
Comrade Igadoter, let's do not run in circles around our own tail!
It may have been mentioned earlier but here's my experience regarding the Plasma crash when trying to mount a partition (a USB key in my case) in dolphin.
I have at the moment two Slackware64 current partitions on the same machine (one will stay current while the other will follow 15.0 in case you wonder). I have updated both current systems to "Wed Jul 21 05:30:44 UTC 2021" except for the kernel:
- On current #1 with kernel 5.12.15 : no crash. I can mount USB key in dolphin (even with solid 5.84)
- On current #2 with kernel 5.13.4 : crash when trying to mount USB key
So it looks like a kernel-induced error.
Again sorry if this has already been explained.
OR, maybe it's a subtle incompatibility of -current's util-linux, and its libmount, with the latest 5.13.x kernel.
but I am running Live Edition of AlienBob. Maybe AlienBob is using own builds of KDE in Live Edition. So at this point I am little out of discussion.
Edit: I read that search module for libmount was added in CMake for KDE 5.83.x. During configuration CMake finds libmount and sets corresponding parameters. Which explains why I don't have link to libmount.
Edit: Because of recent post of gegechris99 maybe it is good idea to test libmount against new 5.13.x kernel.
From what I know, on the other major distributions this /var/run is a symlink to /run and this apply to Debian, Ubuntu, Fedora and openSUSE, etc.
But on Slackware the /var/run is a bind mount of /run, then when we will mount a USB drive, it appears on both locations.
I did a little experiment, replacing on /etc/rc.d/rc.S line 371 this line:
Code:
mount -o bind /run /var/run
with this
Code:
if [ -d /var/run ]; then
# Make the /var/run a symlink to /run
(cd /var
mv run run.orig
ln -sf /run run
)
fi
Rebooted and everything worked fine, with the /var/run becoming a symlink to /run.
Then, I reinstalled the stock solid-5.84 and rebooted again.
For my great surprise, the Plasma5 was loaded normally, and mounting a secondary USB drive worked fine.
In my humble opinion, this is the real issue and that's why the code works for others and not for us sometimes: the way how we handle the /var/run which probably is specific to Slackware.
With the /var/run as specified by FHS 3.0 everything on Plasma5 works fine without a patch needed for solid-5.84.
Last edited by ZhaoLin1457; 07-21-2021 at 04:33 PM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.