document opening hangs depending on order of opening
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
qpdfview |
Incomplete
|
Undecided
|
Unassigned |
Bug Description
Using qpdfview 0.4.18 on MX-Linux 18.3
It used to be possible to open any number of simple/complex documents in any order. Recently the program has started "hanging" on opening a second or subsequent document, especially if it is a "complex" document. By hanging I mean the document fails to render while CPU use is at 100%. The whole window goes unresponsive, it's not possible to switch tabs, close tabs or close the program. Only a kill -9 terminates it.
To demonstrate try opening the attached complex1.pdf followed by EX-17.pdf from a file manager, or using "File/Open in new tab", or at the same time from a command line by ```qpdfview complex1.pdf EX-17.pdf```
Killing the program and opening them in the opposite order works OK.
If the files are all "simple", for example the attached simple1.pdf and simple2.pdf then there is no problem opening as many as desired in any order, eg: simple1, simple2, complex1 is OK, try adding EX-17 and it hangs. The problem is not with EX-17.pdf itself, that's just one of many files which demonstrate the problem.
Machine is Core i5 with 16GB RAM and not resource constrained when opening the files.
Possibly a consequence of updating some packages on 11/11/20 including
```libpoppler-glib8 (0.48.0-2+deb9u3) to 0.48.0-2+deb9u4
libpoppler-qt5-1 (0.48.0-2+deb9u3) to 0.48.0-2+deb9u4
libpoppler64 (0.48.0-2+deb9u3) to 0.48.0-2+deb9u4
...
poppler-utils (0.48.0-2+deb9u3) to 0.48.0-2+deb9u4```
Attaching gdb to a "hung" qpdfview shows it in different places at different times, see the gdb1.txt and gdb2.txt backtraces.
Problem doesn't repro in an MX-19 VM with qpdfview 0.4.17.99
Problem doesn't repro in a Xubuntu 18.04 VM with qpdfview 0.4.14
Hello Mark,
thank you for preparing this detailed bug report! Sadly, I have not been able to reproduce the hang so far. The backtraces are sadly often not helpful as they just contain a lot of generic Qt event processing functions. But since you are able to use gdb, would you be willing to dig into this further and using e.g. "perf top -p $(pidof qpdfview)" [1] to collect a profile during such a hang? This might help us to better isolate which part of the code base is hogging the CPU.
Best regards,
Adam
[1] https:/ /jvns.ca/ blog/2016/ 02/24/perf- top-my- new-best- friend/