[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1040140: libc6: upgrade libc6 to version 2.37-3 break plasma desktop (X11/Wayland)



Hi,

On 2023-07-05 12:55, Antonio wrote:
> Hi,
> 
> I tried the workarounds: they work, however I had left the system with
> overcommit memory 0 (default), since it seemed to be resolved.
> 
> This morning, however, I detected a problem relating to memory (the first
> time I see an OOM-Killer recall process) following an extreme slowdown in
> the system; and I think it could be related to this problem.
> 
> lug 05 12:35:27 kernel: kswapd0 invoked oom-killer:
> gfp_mask=0xcc0(GFP_KERNEL), order=0, oom_score_adj>
> lug 05 12:35:27 kernel: Hardware name: Dell Inc. Precision T1600/06NWYK,
> BIOS A10 02/21/2012
> lug 05 12:35:27 kernel: Mem-Info:
> lug 05 12:35:27 kernel: active_anon:2283373 inactive_anon:768638
> isolated_anon:0
>                                  active_file:5800 inactive_file:5241
> isolated_file:0
>                                  unevictable:39 dirty:52 writeback:0
>                                  slab_reclaimable:17302
> slab_unreclaimable:55651
>                                  mapped:10150 shmem:3002 pagetables:19384
>                                  sec_pagetables:0 bounce:0
>                                  kernel_misc_reclaimable:0
>                                  free:34007 free_pcp:109 free_cma:0
> lug 05 12:35:27 kernel: Node 0 active_anon:9133492kB inactive_anon:3074552kB
> active_file:23200kB inact>
> lug 05 12:35:27 kernel: DMA free:13312kB boost:0kB min:60kB low:72kB
> high:84kB reserved_highatomic:0KB>
> lug 05 12:35:27 kernel: lowmem_reserve[]: 0 3133 15872 15872
> lug 05 12:35:27 kernel: DMA32 free:64276kB boost:0kB min:13328kB low:16660kB
> high:19992kB reserved_hig>
> lug 05 12:35:27 kernel: lowmem_reserve[]: 0 0 12739 12739

Are you sure this is related? From what I have seen the issue increases
the *virtual* memory consumption, but no the memory consumption, so I
don't think that it should trigger the oom killer.

> In my opinion, to avoid stability problems, I think it is preferable to
> perform the revert of the indicated commit, until all any repercussions are
> clarified (rather than configuring the desktops with overrtcommit memory 1).
> 
> What do you think?

There is a patch being discussed upstream [1], the plan is to include it
once it is committed upstream. I also have to check with the release
team if we should delay the transition to testing with another upload,
or upload the fix just after it got migrated.

Regards
Aurelien

[1] https://marc.info/?l=glibc-alpha&m=168849505714289&w=3

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                     http://aurel32.net


Reply to: