Re: More CPU hogging?

[Albrecht Dreß <albrecht dress arcor de>]

Hmmm, the issue still pops up /sometimes/ when I compose a message, using the latest git master.  Any ideas?

Best, Albrecht.

Am 13.02.20 22:03 schrieb(en) Albrecht Dreß:
> Hi all,
>
> running the latest master, I /still/ occasionally observer CPU hogging when I open a composer window; here 
> the output from “top -H -p 9449”:
>
> <snip>
>   PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     ZEIT+ BEFEHL
>  9449 albrecht  20   0 98,802g 125824  62416 R 99,9  1,6   4:29.21 balsa
>  9450 albrecht  20   0 98,802g 125824  62416 S  0,0  1,6   0:00.00 gmain
>  9451 albrecht  20   0 98,802g 125824  62416 S  0,0  1,6   0:00.05 gdbus
>  9464 albrecht  20   0 98,802g 125824  62416 S  0,0  1,6   0:00.00 dconf worker
> 11061 albrecht  20   0 98,802g 125824  62416 S  0,0  1,6   0:00.01 BMScavenger
> 11062 albrecht  20   0 98,802g 125824  62416 S  0,0  1,6   0:00.01 PressureMonitor
> 11063 albrecht  20   0 98,802g 125824  62416 S  0,0  1,6   0:00.00 HashSaltStorage
> 11064 albrecht  20   0 98,802g 125824  62416 S  0,0  1,6   0:00.00 ebsiteDataStore
> 11069 albrecht  20   0 98,802g 125824  62416 S  0,0  1,6   0:00.00 ReceiveQueue
> </snip>
>
> In gdb, the bt of the thread 9949 (actually the main thread) says:
>
> <snip>
> (gdb) bt full
> #0  0x00007fcc22e10567 in __libc_recvmsg (fd=7, msg=0x7fff33a95740, flags=0) at 
> ../sysdeps/unix/sysv/linux/recvmsg.c:28
>         resultvar = 18446744073709551605
>         sc_cancel_oldtype = 0
>         sc_ret = <optimized out>
>         sc_ret = <optimized out>
>         fd = 7
>         flags = 0
>         msg = 0x7fff33a95740
> #1  0x00007fcc16239888 in  () at /usr/lib/x86_64-linux-gnu/libxcb.so.1
> #2  0x00007fcc1623a270 in xcb_poll_for_reply64 () at /usr/lib/x86_64-linux-gnu/libxcb.so.1
> #3  0x00007fcc1ae1ded9 in  () at /usr/lib/x86_64-linux-gnu/libX11.so.6
> #4  0x00007fcc1ae1e20d in _XEventsQueued () at /usr/lib/x86_64-linux-gnu/libX11.so.6
> #5  0x00007fcc1ae0fd3d in XPending () at /usr/lib/x86_64-linux-gnu/libX11.so.6
> #6  0x00007fcc2457c09e in  () at /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
> #7  0x00007fcc232bab28 in g_main_context_prepare () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
> #8  0x00007fcc232bb4fb in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
> #9  0x00007fcc232bb6dc in g_main_context_iteration () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
> #10 0x00007fcc2387ce3d in g_application_run () at /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
> #11 0x0000564c7fc25311 in main (argc=1, argv=0x7fff33a95b68) at main.c:823
>         application = 0x564c805c50f0
>         status = <optimized out>
> </snip>
>
> I guess an other idle thread is kicking in here?
>
> BTW, I see similar effects on the gmime3 branch (but that one seems to be somewhat behind master, right?).
>
> Best,
> Albrecht.

Attachment: pgp9mWKnb4M9b.pgp
Description: PGP signature