Bug 30033

I can't upload it, so I give a link to the log. https://t.me/Mageia_Russian_Community/2931

Please use a program to compress files and upload it here.

Created attachment 13125 [details]
Journalctl

Sorry, I'm on the phone.

found a similar error 
https://bugs.kde.org/show_bug.cgi?id=429939

Depends on: (none) => 30011

> When you try to open plasma settings, they open the settings window
> and close immediately
This is manifestly not generally true. Do you mean "When *I* open ...". You need to give some background:
- has this always happened since you installed Mageia? (Doubtful, you would have reported it sooner).
- When did it start to happen?
- Does it happen repeatedly, or was this a one-off occurrence?

Please post the output of:
 $ inxi -MSG
to say something about your system.
And the terminal output of:
 $ systemsettings5
and the exact package version and fill in the SRPM bug field (both from
 $ urpmq -i systemsettings
)

> Sorry, I'm on the phone
What was this meant to mean? You created your attachment.

Thank you for the journal attachment.
General advice for journal attachments:
 $ journalctl -b --no-hostname
-b restricts journal to current session; --no-hostname makes the lines shorter.
For real 'system' problems, you should be root to see *all* journal messages. But not normally for user-level problems.
As for compressing it, we often recommend 'xz'. But zip (or whatever) is fine.

(In reply to Nikolay Sabelnikov from comment #4)
> found a similar error 
> https://bugs.kde.org/show_bug.cgi?id=429939
Thank you for the URL. However,
"System Settings crashed while attempting to download a theme"
is not what you described.

Ever confirmed: 1 => 0
Status: NEW => UNCONFIRMED
CC: (none) => lewyssmith

I don't have a problem, one of the users, I'll ask him to send me logs.

From viewing the log i would say this system is seriuosly damaged if not tampered with many files. I searched all of my 4 actual Plasma installations on 4 real machines and actualy 2 additional Plasma VMs (one of them cauldron) and couldn't find anything like that from your log file.

This is nearly not possible to troubleshoot. Best would be to check the disk for errors/damage and do a clean installation from scratch.

The system is freshly installed, tomorrow I'll be back, I'll think. You may be right and it's not worth noting.

Created attachment 13126 [details]
Logs (inxi, journalctl...)

I'm sending logs, I didn't find anything critical in the disk.

(In reply to sturmvogel from comment #7)
> From viewing the log i would say this system is seriuosly damaged if not
> tampered with many files. I searched all of my 4 actual Plasma installations
> on 4 real machines and actualy 2 additional Plasma VMs (one of them
> cauldron) and couldn't find anything like that from your log file.
You should not have gone to these lengths: excessively generous!

(In reply to Nikolay Sabelnikov from comment #8)
> The system is freshly installed, tomorrow I'll be back, I'll think. You may
> be right and it's not worth noting.
It is worth noting if it is true. sturmvogel's research makes the system in question suspect.

> (In reply to Nikolay Sabelnikov from comment #6)
> I don't have a problem, one of the users, I'll ask him to send me logs.
* If you are asking for another user - it seems you do not have the problem yourself. You could have said so at the beginning.
* Since this is Plasma, if the user boots from the Plasma Live ISO - does it happen? Or just in the installed system?
* Post the checksum (md5sum) of the ISO he installed from.

You are not answering basic & simple questions that any user would be able to; or would have furnished the information with the bug report.

he used a net-install image, and apparently it's curve + minimal plasma. He had to try with a normal image and a full-fledged plasma. I didn't find any critical problems in the hard data.

Thank you for this clarification.
As a Plasma user, he could easily start from the Plasma Live ISO.
> He had to try with a normal image and a full-fledged plasma
Which ISO? Plasma Live or Classic?
And is the problem still there?

I tried it with a live ISO image, the same thing. Now he is trying a classic image.

even on the classic image, after installation, the kde settings fall.

kernel: systemsettings5[51960]: segfault at b00000020 ip 00007fc26475dc22 sp 00007ffc455250f0 error 4 in libQt5Qml.so.5.15.2[7fc264671000+2b6000]

the same error, if there was a broken disk, then the errors would be chaotic, but there is one tag that says about the incorrect operation of the kde.

The Live is a good test case, that also show this problem in that case.
Quick and most easily repeatable.

I can only think of

a) Incompatible hardware,
b) or broken hardware
c) or maybe it trip on some language encoding 

(Of course it ought to fail gracefully, either case but...)

For c, have you tried Live and selected English locale, just to rule that out?

In Comment 13 you tried and he tried - is it the same machine or two different?

CC: (none) => fri

it's all on the same machine. I doubt if this is a hardware error, then the errors would be chaotic and they would be connected either with the kernel or with the firmware. you can try the version from the cauldron to solve this bug.

As already said we can't reproduce this occurance.
It would maybe help if you could provide the journals from a really clean system installation (the system from comment 9 is an already customized installation with autostart programs, wallpapers and themes)or from the test with the live iso.

And i mean a relly clean installation with a fresh test user (anything other than PID 1000) and not the same /home.

As I understood from his message, at first the window will not fall, then after setting up the system, the settings begin to fall.
I quote his message:
"Fara:
Well, it happens differently in different cases. In this case, I changed the theme to dark, removed the actions from the unnecessary edges of the screen, then tried to change the lock screen wallpaper and it fell
I downloaded the wallpaper, I wanted to apply it, but it wasn't there, I fell)
They randomly fall, you just need to sit in them and poke the settings) "

He reinstalled the system 3 times, from different images, with new users, but the problem still manifests itself. Also reinstalled the task.

You can't "reinstall" a "task" package easily. To do so you have to remove all Plasma related packages via the "urpme --auto-orphans task-plasma5 task-plasma5-minimal" mechanism and reinstall the task package (including round about 170 packages) afterwards again. You have to do this from another desktop environment or prior starting X.

So please provide logs from a clean system.

You may not be able to reproduce, as such a problem can be 1 in a million.

(In reply to sturmvogel from comment #21)
> You can't "reinstall" a "task" package easily. To do so you have to remove
> all Plasma related packages via the "urpme --auto-orphans task-plasma5
> task-plasma5-minimal" mechanism and reinstall the task package (including
> round about 170 packages) afterwards again. You have to do this from another
> desktop environment or prior starting X.
> 
> So please provide logs from a clean system.

He first removed the task with dependencies, then put it for a new one.

The initial log was from a clean system, he just installed it, and this is the problem that appeared. reinstalled the same thing 3 times. Everything works, and the settings window does not fall.

Moreover, here is the very reason for the drop in settings
kernel: systemsettings5[4951]: segfault at 20000001f ip 00007f3ea0422c22 sp 00007ffec8a187f0 error 4 in libQt5Qml.so.5.15.2[7f3ea0336000+2b6000]

(In reply to Nikolay Sabelnikov from comment #24)
> The initial log was from a clean system, he just installed it, and this is
> the problem that appeared. 

Honestly? Both provided logs are definitly not a clean system. Additional programs like Telegram got installed, special themes for sddm greeter got installed, a manga style wallpaper got installed,...

We try to help you but you make it really hard for us. As an specialist for IT-Systems (according your signature) you should be well aware how important it is to provide precise, full, understandable, repeatable informations to troubleshoot a problem. Especially if it is a problem "on 1 system out of a million".

Additionally it is not really helpfull that the affected user doesn't communicate himself. It's honorable that you try to help him, but you are acting like a catalysator so maybe some informations from to user get lost on the way to us.

(In reply to Nikolay Sabelnikov from comment #25)
> Moreover, here is the very reason for the drop in settings
> kernel: systemsettings5[4951]: segfault at 20000001f ip 00007f3ea0422c22 sp
> 00007ffec8a187f0 error 4 in libQt5Qml.so.5.15.2[7f3ea0336000+2b6000]

The log from comment 9 doesn't have this line.

I suggest we leave it there if user is happy.
This seem like a rare corner case.

Thank you Nikolay and sturmvogel for trying to chase it down.

If problems reappear and user is an adventurous type, he may like to try cauldron, when it is relatively stable (not currently) and have the new Plasma 5.24.

Status: UNCONFIRMED => RESOLVED
Resolution: (none) => WORKSFORME

(In reply to sturmvogel from comment #27)
> (In reply to Nikolay Sabelnikov from comment #25)
> > Moreover, here is the very reason for the drop in settings
> > kernel: systemsettings5[4951]: segfault at 20000001f ip 00007f3ea0422c22 sp
> > 00007ffec8a187f0 error 4 in libQt5Qml.so.5.15.2[7f3ea0336000+2b6000]
> 
> The log from comment 9 doesn't have this line.

here it is
Feb 11 20:05:55 dxd kernel: systemsettings5[15063]: segfault at 20000001f ip 00007f48f7371c22 sp 00007ffe7b6df430 error 4 in libQt5Qml.so.5.15.2[7f48f7285000+2b6000]

(In reply to Morgan Leijström from comment #28)
> I suggest we leave it there if user is happy.
> This seem like a rare corner case.
> 
> Thank you Nikolay and sturmvogel for trying to chase it down.
> 
> If problems reappear and user is an adventurous type, he may like to try
> cauldron, when it is relatively stable (not currently) and have the new
> Plasma 5.24.

But the problem is not solved. That's what I'm saying, it looks like a rare case. I can't reproduce it either.

(In reply to Nikolay Sabelnikov from comment #24)
> Everything works, and the settings window does not fall.


?

(In reply to sturmvogel from comment #31)
> (In reply to Nikolay Sabelnikov from comment #24)
> > Everything works, and the settings window does not fall.
> 
> 
> ?

I apologize for the incorrect translation.

Resolution: WORKSFORME => (none)
Status: RESOLVED => REOPENED
Ever confirmed: 0 => 1

So you have created an upstream bug report; thank you.
It would be worth putting this Mageia bug URL:
 https://bugs.mageia.org/show_bug.cgi?id=30033
in that KDE bug.

It looks as if this happens only with this user on one machine, unpredictably. The KDE people will chase you for more precise information; there is no way this can be resolved in the present fog of uncertainties.
If the actual user does not want to communicate himself, is it because he does not have English? Sympathise, but we are not up to handling Russian.

For the record, please post the output of:
 $ inxi -MSGxx
from the user's system.
-----------------------
We are getting nowhere, & cannot advance on this obscure & unique problem. 
I am closing the bug, but you can re-open it if you come up with some useful information.

Status: UNCONFIRMED => RESOLVED
Resolution: (none) => WORKSFORME

I rediscover, as there is a problem, it is not solved.

Resolution: WORKSFORME => (none)
Status: RESOLVED => REOPENED
Ever confirmed: 0 => 1

It was found that the file is not located 
qqmldata_p.h
output of the list command to gdb after the
in ../../include/QtQml/5.15.2/QtQml/private segment/../../../../../ src/qml/qml/qqmldata_p.h
list 1
file: "../../include/QtQml/5.15.2/QtQml/private/../../../../../src/qml/qml/qqmldata_p.h", line number: 1, symbol: "???"
1 ../../include/QtQml/5.15.2/QtQml/private/../../../../../src/qml/qml/qqmldata_p.h: No such file or directory.

This only means that libqt5qml-devel-5.15.2-1.mga8 is not installed. This is a devel package and absolutly not necessary to run Plasma.
Can easily be found with our Database.

Or lib64qt5qml-devel-5.15.2-1.mga8 in case of x86_64

(In reply to sturmvogel from comment #37)
> Or lib64qt5qml-devel-5.15.2-1.mga8 in case of x86_64

this lib was installed, the file was substituted where it was requested, the settings window no longer fell. The question remains, why did he have this file missing?

As you or the user didn't provide enough informations to recreate the problem it is hard to say why he needs a developement package on his system to run Plasma. On a normal Plasma installation (a non developer setup) without any tampered filepaths/settings/files a devel package is not needed to run Plasma properly.

Even on my machines where i have setup a building environment this devel package was never needed to run Plasma properly.

I'm running KDE/Plasma since Mandrake/Mandriva times.

(In reply to sturmvogel from comment #39)
> As you or the user didn't provide enough informations to recreate the
> problem it is hard to say why he needs a developement package on his system
> to run Plasma. On a normal Plasma installation (a non developer setup)
> without any tampered filepaths/settings/files a devel package is not needed
> to run Plasma properly.
> 
> Even on my machines where i have setup a building environment this devel
> package was never needed to run Plasma properly.
> 
> I'm running KDE/Plasma since Mandrake/Mandriva times.

here the essence of the problem is different. Why this file was missing, and not because you can't reproduce it. According to the logs, the problem was obvious and here is its solution. maybe the problem is in the build or source code.

 -devel packages should not be required for end users.
If your users machine requires it, that reason have to be investigated.

Nikolay, do you have it on your Mageia system?

I dont have that one on mine, and I run Plasma.

$ sudo rpm -qa | grep lib64qt5qml
lib64qt5qmlmodels5-5.15.2-1.mga8
lib64qt5qmlworkerscript5-5.15.2-1.mga8
lib64qt5qml5-5.15.2-1.mga8

the problem is not with my PC, but with the PC of a person from the Russian community. On my own PC, I also do not observe this, so that a regular package requires developer files.

sudo rpm -qa | grep lib64qt5qml
lib64qt5qml-devel-5.15.2-1.mga8
lib64qt5qmlworkerscript5-5.15.2-1.mga8
lib64qt5qmlmodels5-debuginfo-5.15.2-1.mga8
lib64qt5qml5-debuginfo-5.15.2-1.mga8
lib64qt5qml5-5.15.2-1.mga8
lib64qt5qmlworkerscript5-debuginfo-5.15.2-1.mga8
lib64qt5qmlmodels5-5.15.2-1.mga8

When you write, you must be clear.  Is comment 43 from the problematic install, and that user have manually added lib64qt5qml-devel-5.15.2-1.mga8 and the debuginfo packages?

And systemsettings sometimes segfaulted before -devel was added?
And but never after?


Little education exercise:

The package(s) containing specific file(s) can be found using i.e

$ urpmf qqmldata_p.h
lib64qt5qml-devel:/usr/include/qt5/QtQml/5.15.2/QtQml/private/qqmldata_p.h                                                                                         
libqt5qml-devel:/usr/include/qt5/QtQml/5.15.2/QtQml/private/qqmldata_p.h 
(also lists the file lists it downloads for searcuing)

The package system is right to have not installed -devel as it is only needed by other -devel packages, see
$ urpmq --whatrequires-recursive lib64qt5qml-devel

So the question is what evenso need that file in this particular case.
I would say that is not a case for Mageia to hunt, but a Plasma forum / Plasma bugtracker.

Please try to see what you and that user can find there, then get back.

For starting, some hits are found by web searching 'plasma qqmldata_p.h' but that may be completely irrelevant.

IMO we should leave this with user knowing the workaround for his odd case.

If it were repeatable and more common we would enter it under
https://wiki.mageia.org/en/Mageia_8_Errata#Plasma

Also i believe KDE developers are not interested unless you can repeat it under their latest version.

In KDE bug tracker there are lots of similar odd glitches never tracked down...

Anyway, Not Our Bug (tm) :)

Summary: [Bug]: plasma settings fall => Plasma settings segfault in rare conditions

(In reply to Morgan Leijström from comment #45)
> IMO we should leave this with user knowing the workaround for his odd case.
> 
> If it were repeatable and more common we would enter it under
> https://wiki.mageia.org/en/Mageia_8_Errata#Plasma
> 
> Also i believe KDE developers are not interested unless you can repeat it
> under their latest version.
> 
> In KDE bug tracker there are lots of similar odd glitches never tracked
> down...
> 
> Anyway, Not Our Bug (tm) :)

this segfault causes the settings window to crash. It was also discovered on his system, another segfault only with the zypper package manager.
kernel: zypper[19167]: segfault at 18 ip 00007f7ca6abb492 sp 00007ffed644db00 error 4 in libpthread-2.32.so[7f7ca6ab5000+e000]

To do this, I opened a bug and sent the information to bugs kde

I jump back in late.

(In reply to Nikolay Sabelnikov from comment #38)
> (In reply to sturmvogel from comment #37)
> > Or lib64qt5qml-devel-5.15.2-1.mga8 in case of x86_64
> this lib was installed, the file was substituted where it was requested, the
> settings window no longer fell. The question remains, why did he have this
> file missing?
Congratulations on finding this bizarre solution.
This package is definitely not 'missing' from any normal system; it is never present. My own system, which has many desktops, (also other people's), does NOT have this package, without any problem. Looking at what requires it, it is *only* other *-devel packages.

(In reply to Nikolay Sabelnikov from comment #42)
> the problem is not with my PC, but with the PC of a person from the Russian
> community. On my own PC, I also do not observe this
Good to know. Morgan's idea that it might be an obscure language issue is thus discounted.

> so that a regular package requires developer files.
Unclear what you mean. In this particular and unique case?

It is undoubted that this strange problem happens on one particular machine, whose user is not in direct contact (accepting the language difficulty).
And about which you have yet to provide any information...

Of course we want to see it fixed, but in the contradicting circumstances, even with the crash evidence, there is nothing we can do.
I hope your upstream bug makes it clear that:
- the problem is unique to this user/system
- Mageia applications never require -devel packages
- no comparative system, without the bug, has the package in question
- cite this bug reference https://bugs.mageia.org/show_bug.cgi?id=30033

Once again, we are pleased that you found your own solution.

(In reply to Nikolay Sabelnikov from comment #46)
> It was also discovered on
> his system, another segfault only with the zypper package manager.
> kernel: zypper[19167]: segfault at 18 ip 00007f7ca6abb492 sp
> 00007ffed644db00 error 4 in libpthread-2.32.so[7f7ca6ab5000+e000]
This is peculiar. Why 'zypper' on a Mageia system? We say "The XML based repository metadata used by this package manager is not available on Mageia mirrors so it cannot be used for regular package installation."
There is undoubtedly something very odd about this user's system.

Re-open the bug if you get any upstream feedback.

Status: UNCONFIRMED => RESOLVED
Resolution: (none) => WORKSFORME

Let's look at the kde solution, although I am sure that they will no longer fix this bug in version 5.20, but perhaps the fix will be in the 5.24 lts.

zypper is in turnips. https://madb.mageia.org/rpm/show/application/0/arch/x86_64/name/zypper-1.14.42-1.mga8.x86_64.rpm/source/0/release/8/t_media/3
we will wait for a response from kde.

(In reply to Nikolay Sabelnikov from comment #46)
> It was also discovered on
> his system, another segfault only with the zypper package manager.
> kernel: zypper[19167]: segfault at 18 ip 00007f7ca6abb492 sp
> 00007ffed644db00 error 4 in libpthread-2.32.so[7f7ca6ab5000+e000]
Please open another bug for zypper. And try and provide some information. I suggest:
* $ inxi -MS
to give some system information.
* Say exactly what ISO was used for the system installation.
* If it is

[continued: scrap previous 1/2 sentance]
* Say in what circumstances the fault occurs, how to make it happen: always, sometimes, after doing something specific?
* Post the terminal output leading to a crash:
 $ zypper
* $  rpm -q zypper
to give the exact version.
* If the fault is reproduceable, and the system is Plasma, please try it directly from the Live ISO (without touching the disc). He will need to specifically install 'zypper' in the Live session. Does the same fault happen?
* Install zypper yourself and try the fault. [I have just done so, and launching zypper with no parameters works - outputs help information].

Hello. It turned out that he is not the only one who has this bug. My bug was marked as a double.

Ever confirmed: 0 => 1
Resolution: WORKSFORME => (none)
URL: https://bugs.kde.org/show_bug.cgi?id=450164 => https://bugs.kde.org/show_bug.cgi?id=426047
Status: RESOLVED => REOPENED

Thank you for the update.

More specifically there are four duplicates of the upstream bug.

Interesting is that at least one of the upstream duplicate bugs tell like comment 35 above, installing the file qqmldata_p.h works around the bug (at least by installing the devel package, see comment 38)

I doubt KDE will fix it in our Mageia 8 version.

At least lets leave this bug open so the workaround can be found.

KDE maintainers: this problem seem to be hit, but rarely.
Easy to fix?
Is there a full KDE update on the horizon?

Status comment: (none) => Workaround in comment 35..38
Whiteboard: (none) => WORKAROUND
Assignee: bugsquad => kde

In mageia 8, it does not seem to appear, because version 9 is already on the horizon, and in cauldron the plasma version is 5.23.4. why was it not brought to 5.24.0 (lts)? it's not clear. By the release of mageia 9, the plasma would have been brought to mind in the upstream.

it will be solved in the 6th version of plasma.