All Things KDE5/Plasma for Slackware Users.

bassmadrigal · 07-21-2021, 12:33 PM

Quote:

Originally Posted by atelszewski

Hi,

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.

igadoter · 07-21-2021, 12:33 PM

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

Code:

$ mount

with

Code:

$ cat /proc/self/mountinfo

To feel totally dumb test the size

Code:

$ ls -l /proc/self/mountinfo

igadoter · 07-21-2021, 01:36 PM

Quote:

Originally Posted by LuckyCyborg

Maybe the way we build util-linux affects this solid-5.84 ? How?

It seems that libmount is used to enumerate /proc/self/mountinfo.

LuckyCyborg · 07-21-2021, 01:46 PM

Quote:

Originally Posted by igadoter

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.

igadoter · 07-21-2021, 01:48 PM

Did you notice my post about libmount? As for me it is main suspect now.

KDE is using libmount. Possible scenario libmount fails - KDE crashes. Probably downgrade would give some insight.

LuckyCyborg · 07-21-2021, 01:54 PM

Quote:

Originally Posted by igadoter

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?

atelszewski · 07-21-2021, 02:29 PM

Hi,

Quote:

Originally Posted by bassmadrigal

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_.

--
Best regards,
Andrzej Telszewski

gegechris99 · 07-21-2021, 02:34 PM

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.

igadoter · 07-21-2021, 03:18 PM

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.

LuckyCyborg · 07-21-2021, 03:29 PM

Quote:

Originally Posted by igadoter

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!

Code:

vanya@darkstar:~$ ldd /usr/lib64/libKF5Solid.so.5.84.0 | grep libmount
        libmount.so.1 => /lib64/libmount.so.1 (0x00007f68a47f1000)
vanya@darkstar:~$

Did you want screenshot?

LuckyCyborg · 07-21-2021, 03:31 PM

Quote:

Originally Posted by gegechris99

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.

igadoter · 07-21-2021, 03:40 PM

I found this thread https://forums.gentoo.org/viewtopic-...2-start-0.html is old but points into direction of elogind. Posters noted similar behavior as here when attempt to mount device.

LuckyCyborg · 07-21-2021, 03:48 PM

Quote:

Originally Posted by igadoter

I found this thread https://forums.gentoo.org/viewtopic-...2-start-0.html is old but points into direction of elogind. Posters noted similar behavior as here when attempt to mount device.

Did you really believe that someone being unauthorized to mount a flash drive is similar with our panels crash on mounting a flash drive?

What they hit is logind authorization, what we hit is some code written on top of libmount doing nasty things. Those are totally different things.

igadoter · 07-21-2021, 03:52 PM

Quote:

Originally Posted by LuckyCyborg

Code:

vanya@darkstar:~$ ldd /usr/lib64/libKF5Solid.so.5.84.0 | grep libmount
        libmount.so.1 => /lib64/libmount.so.1 (0x00007f68a47f1000)
vanya@darkstar:~$

Did you want screenshot?

Don't need

Code:

$ ldd /usr/lib64/libKF5Solid.so.5.79.0   | grep libmount
$

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.

ZhaoLin1457 · 07-21-2021, 04:31 PM

I have found a very interesting thing, which may explain why the other major distributions are not affected by this issue.

According with the Filesystem Hierarchy Standard 3.0 the /var/run should be either a standalone directory or a symlink to /run

https://en.wikipedia.org/wiki/Filesy...archy_Standard

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.