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 aurel...@aurel32.net http://aurel32.net
