Bug#1040140: libc6: upgrade libc6 to version 2.37-3 break plasma desktop (X11/Wayland)
Hi,
On 2023-07-03 14:27, Antonio wrote:
> I carried out further tests, until I replicated the problem on a virtual
> machine.
>
> Then I compared the plasma configuration subdir with a functioning version
> (obtained experimentally, resetting the arrangement of the desktop and
> windows, from default breeze theme).
>
> The difference that determines the problem is in the
> "~/.config/plasma-org.kde.plasma.desktop-appletsrc", section
> "[Screenmapping]".
>
> I noticed that "itemsondisabledscreens" and "screenmapping" items have an
> excessive line length.
>
> LENGTH LINE
> BYTES FIRST 200 chars
> 82 --- ok-plasma-org.kde.plasma.desktop-appletsrc 2023-07-03
> 13:26:44.894
> 83 +++ bad-plasma-org.kde.plasma.desktop-appletsrc 2023-07-03
> 12:35:57.69
> 16 [ScreenMapping]
> 24 -itemsOnDisabledScreens=
> 392
> -screenMapping=desktop:/4.png,0,71c04f84-b363-4dca-a9a8-671fbb033f34,d...
> 14110
> +itemsOnDisabledScreens=2,19c9821c-6bd3-4d27-b17a-1e325203a1fc,1,deskt...
> 3994359
> +screenMapping=desktop:/safekernel-bk110323.01-rel6.1.18/build/include...
>
> This was also noted from the file size:
>
> Bad:
> -rw------- 1 root root 37K Jul 3 13:43
> ~/.config/plasma-org.kde.plasma.desktop-appletsrc
>
> Good:
> -rw------- 1 root root 12549 3 lug 13.47
> ~/.config/plasma-org.kde.plasma.desktop-appletsrc
>
> If I remove the entire section, everything works well.
Thanks a lot for investigating. With that details, I was able to
reproduce the issue in a VM.
> I don't know why, but these lines have elongated dramatically. Perhaps the
> processes that manage them do not control the maximum length of the lines
> ...
>
> With the previous version of Libc this problem had never occurred, even in
> the presence of these lines; while with the new version he came out.
It's not clear to me either what's the issue. So far I have just found
that the virtual memory allocation of plasmashell is ~11GB with glibc
2.37 vs ~2GB with glibc 2.36. In both cases the resident memory is
around 350MB. This higher virtual memory allocation seems to cause the
clone syscall to fail with -ENOMEM.
> However, now the problem seems to have solved.
Yes, it's great that you have found a workaround. Given that, I don't
think it warrants blocking the migration of glibc 2.37 to testing, but
I'll continue investigating to better understand if it could have other
side effects.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://aurel32.net
Reply to: