search

michaelrsweet / pappl

PAPPL - Printer Application Framework
https://www.msweet.org/pappl
Apache License 2.0
309 stars 49 forks source link

When a Printer Application is running as server, after some operations it takes 100% CPU #218

Closed tillkamppeter closed 2 years ago

tillkamppeter commented 2 years ago

Describe the bug When a Printer Application is running as server, after some operations it takes 100% CPU. Operations can be printing a job/the test page but also admin operations like identifying the printer, polling defaults/accessories from the printer (PostScript Printer Application), ... usually any operation which interacts with the printer and can be easily triggered by the web interface of the Printer Application.

Investigating what actually takes the 100% CPU is the thread which is spawned to register the services (system, each printer) with Avahi, so that they get advertised via DNS-SD. The main thread registers the services at Avahi via Avahi's API functions and Avahi spawns a thread as it does a Threaded Poll. This thread is the one grabbing 100% CPU (I have found it out by running the Printer Application under the operf utility and processing the results with oprofile, then I have also started the Printer Application under gdb, interrupted with Ctrl+C, and stack-traced to see what the threads are for). The main thread, once having registered the services and going into the main loop, spawns a thread by itself for each inquiry, but these threads cleanly finish (also in a complex Printer Application using pappl-retrofit) not leaving any runaway thread and stays idling around when one stops doing operations. Independent of this, the Avahi thread ramps up to 100% CPU after the first operation and if not, after the 3rd, 4th, 5th ... operation. Once up to 100% CPU it stays there. The problem is not caused by libpappl-retrofit or libcupsfilters, as it also occurs with the example Printer Application which comes with PAPPL, too.

To Reproduce

  1. Run top in a terminal window
  2. Start the example Printer Application which comes with PAPPL as a server (./testpappl).
  3. Open its web interface (https://localhost:8000/ if no other Printer Application is running, otherwise port 8001, 8002, ...).
  4. Choose one of the print queues and click "Identify" or "Print test page".
  5. Observe the top output. After some seconds the CPU occupation of testpappl ramps up to 100%. If not, repeat step 4. After a maximum of ~5 times it should occur, in most cases right at the first time.

NOTE: It is possible that it only occurs when the queue points to a real printer. If the sample queues which come with testpappl do not make the bug getting reproduced, create a new queue with a real printer (USB or network) and do the steps with this one.

Expected behavior CPU consumption of a Printer Application should be negligibly small when the Printer Application is idle.

System Information:

michaelrsweet commented 2 years ago

[master a42fe51] Fix 100% CPU bug when cleaning out old jobs (Issue #218)

[v1.2.x 1557965] Fix 100% CPU bug when cleaning out old jobs (Issue #218)

tillkamppeter commented 2 years ago

Thank you very much, it works!

So it was permanent cleaning of the job lists.

The Snap Store is rebuilding all my 4 retro-fitting Printer Application Snaps now ... (do not forget LPrint and hp-printer-app, Mike ...).

tillkamppeter commented 2 years ago

Found another 100%-CPU problem in pappl-retrofit, so for the retro-fitting Printer Applications this needs to get updated, too. Snap Store rebuilding all my 4 retro-fitting Printer Application Snaps again ...

tillkamppeter commented 2 years ago

Fortunately there was no Avahi bug involved ...