Re: More CPU hogging?

Hi Albrecht:

On 02/25/2020 10:19:43 AM Tue, Albrecht Dreß wrote:
> Hmmm, the issue still pops up /sometimes/ when I compose a message, using the latest git master.  Any ideas?
> 
> Best, Albrecht.

That's odd--I haven't come across that (or haven't noticed it).

Only one function in src/sendmsg-window.c is scheduled by g_idle_add(), and it looks harmless: it never returns G_SOURCE_CONTINUE, which was the cause of the recent spate of CPU hogging. Likewise, none of the calls in other modules that open a compose window seems to be linked to an idle handler. But frame #9, g_main_context_iteration (), does look like it could be part of an idle-callback flood.

If you get a chance, could you get back traces for all threads?

Peter

> 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/libX11so.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.so0
>> #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.

_______________________________________________
balsa-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/balsa-list

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQS030wPRfNNA5alz3MfX9S1uSp09QUCXlVb5AAKCRAfX9S1uSp0
9S90AJ4qGnRXaFl5pOLbjWfdBAGRn7YBmQCfdxp9lJ+cfXZgG8AAMZzOCl0C2tU=
=ShaO
-----END PGP SIGNATURE-----