[kde] [Bug 504487] [ANR] Closing the "Keyboard Shortcuts" window whilst it is waiting for the "Print" window to appear causes a crash.

[Roke Julian Lockhart Beedell]

https://bugs.kde.org/show_bug.cgi?id=504487

--- Comment #11 from Roke Julian Lockhart Beedell <4wy78uwh at rokejulianlockhart.addy.io> ---
Created attachment 181658
  --> https://bugs.kde.org/attachment.cgi?id=181658&action=edit
A KCrash For Krita

(In reply to Nate Graham from comment #9)

> Why were you trying to open the print dialog if you don't have a printer? To make a PDF?

Yes. I thought it might be a useful way to visualise (or, crudely, backup)
keyboard shortcuts.

(In reply to Mike from comment #10)

> there is at least one timeout in the code path, maybe two.

I've captured a Perf and STrace record, if of use. I've plonked them in
https://collaborate.kde.org/apps/files/files/684451?dir=/%27Custom%27%23.dir/%27Publicly%20Accessible%27%23.dir/%27bugs.KDE.org%27%23.dir/%27504487%27%23.dir,
but shall attach them once I've submitted this comment.

About STrace, I saw, whilst the printer is loading, a multitude of ultimately
quite quick calls, repeatedly occurring until the dialog appears:

> 0.000048 read(28, "W", 10)         = 1 <0.000011>  
> 0.000030 poll([{fd=28, events=POLLIN}, {fd=30, events=POLLIN}], 2, 50) = 0 (Timeout) <0.050086>  
> 0.050137 poll([{fd=28, events=POLLIN}, {fd=30, events=POLLIN}], 2, 50) = 0 (Timeout) <0.050083>  
> 0.050127 poll([{fd=28, events=POLLIN}, {fd=30, events=POLLIN}], 2, 50) = 0 (Timeout) <0.050084>  
> 0.050134 poll([{fd=28, events=POLLIN}, {fd=30, events=POLLIN}], 2, 50) = 0 (Timeout) <0.050091>  
> 0.050139 poll([{fd=28, events=POLLIN}, {fd=30, events=POLLIN}], 2, 50) = 0 (Timeout) <0.050088>  
> 0.050154 poll([{fd=28, events=POLLIN}, {fd=30, events=POLLIN}], 2, 50) = 0 (Timeout) <0.050088>  
> 0.050147 poll([{fd=28, events=POLLIN}, {fd=30, events=POLLIN}], 2, 50) = 0 (Timeout) <0.050088>  
> 0.050135 poll([{fd=28, events=POLLIN}, {fd=30, events=POLLIN}], 2, 50) = 0 (Timeout) <0.050088>  
> 0.050134 poll([{fd=28, events=POLLIN}, {fd=30, events=POLLIN}], 2, 50) = 0 (Timeout) <0.050078>  
> 0.050122 poll([{fd=28, events=POLLIN}, {fd=30, events=POLLIN}], 2, 50) = 0 (Timeout) <0.050081>  
> 0.050126 poll([{fd=28, events=POLLIN}, {fd=30, events=POLLIN}], 2, 50) = 0 (Timeout) <0.050080>  
> 0.050126 poll([{fd=28, events=POLLIN}, {fd=30, events=POLLIN}], 2, 50) = 0 (Timeout) <0.050097>  
> 0.050146 poll([{fd=28, events=POLLIN}, {fd=30, events=POLLIN}], 2, 50) = 0 (Timeout) <0.050041>  
> 0.050095 poll([{fd=28, events=POLLIN}, {fd=30, events=POLLIN}], 2, 50) = 0 (Timeout) <0.050088>  
> 0.050139 poll([{fd=28, events=POLLIN}, {fd=30, events=POLLIN}], 2, 50) = 0 (Timeout) <0.050089>  
> 0.050148 poll([{fd=28, events=POLLIN}, {fd=30, events=POLLIN}], 2, 50) = 0 (Timeout) <0.050090>  
> 0.050160 poll([{fd=28, events=POLLIN}, {fd=30, events=POLLIN}], 2, 50) = 0 (Timeout) <0.050088>  
> 0.050151 poll([{fd=28, events=POLLIN}, {fd=30, events=POLLIN}], 2, 50) = 1 ([{fd=30, revents=POLLIN}]) <0.048304>  
> 0.048380 recvmsg(30, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\4\1\1\0\0\0\0\220\0\0\0\215\0\0\0\1\1o\0\31\0\0\0/Client1"..., iov_len=2048}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 320 <0.000034>

>From what I see, this doesn't occur before or after I invoke the dialog.

...About CUPS:

> One thing you could try is to turn off your networking, then try the print and see if the dialog still takes "a while" to present.  CUPS will do some IPP/network "stuff" to discover printers on your net.
> 
> You could disable CUPS `sudo systemctl stop cups.service` and then try the print and see what happens there.

I stopped it, and verified it was:

> Loaded: loaded (/usr/lib/systemd/system/cups.service; disabled; preset: disabled)

This made it almost ⪆ 4s faster, but it still takes ⪅ 2.5s to appear, which is
still bad on a system with 32 GiB of DDR5 SDRAM! 😆 However, disabling Ethernet
reduced it by *maybe* ⪅ 0.5s, if I'm not merely experiencing confirmation bias
/ placebo / whatever. I suppose we can consider CUPS the most *significant*
culprit, but on Windows, this is instantaneous, so there's more at play.

(In reply to Roke Julian Lockhart Beedell from comment #6)

> This *does not* affect Krita, nor SkanPage

It *does* affect Krita too, per
https://discuss.kde.org/t/is-a-kde-application-not-providing-a-bug-reporting-address-a-bug/34640?u=rokejulianlockhart.
The reason SkanPage doesn't appear affected appears to be that it solely
exposes one keyboard shortcut. At least that demonstrates that the quantity of
shortcuts affects invocation time. I'll presume you knew this, though, you
backtrace-reading nutters.

-- 
You are receiving this mail because:
You are the assignee for the bug.