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.
Attachment:
pgp7X_QxXLFPo.pgp
Description: PGP signature