libksane seems to break QProcess::start calls

Klaas Freitag freitag at kde.org
Thu Mar 3 16:33:00 GMT 2022


Am 03.03.22 um 13:54 schrieb Tobias Leupold:
Hi Tobias,


> I have a very odd problem, and I have no idea what could cause this or even
> how to debug this. maybe, someone of you can give me a hint.
> 
> I revently wrote a small helper program for one special purpose: Scanning
> documents at a defined size, post processing them a bit and saving the
> processed, compressed images as a PDF file to e.g. send them via mail. The
> sources can be found at https://invent.kde.org/tleupold/scandoc/ .

Interesting, I wrote a very similar little utility called PDFQuirk:
https://dragotin.github.io/quirksite/

> It uses libksane, ImageMagick's convert and pdfjam as helper programs. This
> may be too special or too hacky to become e.g. an official KDE extragear
> program, but that's another thing.

PDFQuirk has a very similar idea, yet it does not use libksane, but the 
command line tool scanimage directly, started via QProcess. The idea 
behind that is that the users should not need to tweak around with 
scanner settings after the 'admin' set them, as in the average office, 
the scanner does not change so often...

> However the problem is:
> 
> As said, the program uses convert to post process the scanned images. I use
> QProcess to run the respective command, in a procedural, synchronous way, as
> the command is typically finished within fractions of a second. The call
> strips down to:
> 
>      QProcess process;
>      process.start(command, arguments);
>      waitForFinished();
> 
> Using one scanner I have (it's a Brother MFC device), this works without a
> problem. Everything is fine. But using another one, a CanoScan LiDE 25, a
> really strange problem happens:

As this only happens with one scanner and works fine with the other 
(right?), I would point to the scanner driver that is loaded by sane.
Have you tried the scanimage command line utility from SANE if it works 
with the scanner in question?

regards,

Klaas

> 
> After having scanned the first page, everything works as expected. But after
> having scanned the second one, the QProcess call doesn't exit anymore. It runs
> normally, and the output file is created. But it doesn't return, until it's
> killed by the waitForFinished() call. ps lists the process as "defunct".
> 
> As expected, the GUI freezes for 30 seconds (the default timeout). But after
> the process is killed, the GUI is still frozen for another 30 seconds (why?!),
> then it becomes responsive again and the post processed image is added like if
> the call would have exited normally.
> 
> It's also not about the "convert" call. Each and every QProcess I start after
> the seconds scan does not exit anymore. Even something like "dmesg" or such.
> After the first scan, everything is fine, after the second scan,
> QProcess::start does not exit anymore. As long as I don't do a second scan, I
> can start as many QProcess processes as I want, and all exit normally. But not
> anymore after the second page.
> 
> I also tried to create the QProcess on the heap, and to implement the command
> run asynchronously. The result is the same: After the first scan, the process
> returns normally, after the second scan, it doesn't exit anymore ("can't
> start, already running").
> 
> To make it even more peculiar: At first, I implemented the convert process to
> read from stdin and write to stdout, piped the image data to it, and read the
> output to get the processed image directly. This caused no problem, no matter
> how much scans I did. But later on, I needed to call programs not reading from
> stdin.
> 
> So ... how can that even happen? Where do the 30 seconds unresponsiveness come
> from, after the QProcess has already been killed?! Is this something that
> libksane causes? How can it influence a completely unrealted QProcess call? Or
> did I simply write crappy code?!
> 
> If anybody has any idea about this, I would really appreciate some
> enlightenment ;-)
> 
> Thanks for all help in advance!
> Cheers, Tobias
> 
> 



More information about the kde-devel mailing list