Bug 395391

Summary:	Scan larger than about 2GB generate std::bad_alloc on x64 server with >> 30GB free RAM
Product:	[Applications] Skanlite	Reporter:	Bob Mahar <bob>
Component:	general	Assignee:	Kåre Särs <kare.sars>
Status:	REPORTED ---
Severity:	crash
Priority:	NOR
Version First Reported In:	2.1.0.1
Target Milestone:	---
Platform:	openSUSE
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Bob Mahar 2018-06-14 19:26:16 UTC

Running openSUSE Tumbleweed x64 with latest patches from SUSE repos. HW is intel based HP server with > 64GB of RAM, mostly all available. ulimit unlimited, confirmed via /proc/PID/limits. Scanner is Canon F9000 mk II.

At 4800 DPI, it is possible to select a region large enough that eventually the scan process abnormally terminates with std::bad_alloc. The issue is reproducible ( on my systems at least ) with any region which equates to about 2GB of image data.

I nudged the borders around and could get it down to +/- a few pixels making the difference. For example 30170 x 12030 x 6 bytes ( 48 bit ) was OK, slight more in either x or y width caused the issue, slightly less, OK. I changed the orientation of the selection to roughly 11000 x 32000 and around the same size ran into similar issues. Position of the selection did not matter.

One hallmark of the issue, in the UI, is that the scan progress indicator does not advance during the scan and is stuck at 0%, also the visual progress on the selection box actually fills outside of the selection and works its way vertically towards the top. So the problem may start early on. The scanner is scanning, and you can see a lot of CPU and memory churn for the skanlite process and SANE threads. So it seems to be scanning.

Though the progress bar is dead and the "completed" scan indicated in the UI is marching in the wrong direction, the UI still works. I can cancel the scan, change the selection, and start over. If I let the scan continue, however, after a while I get the allocation error.

So trying various sizes and bit depths, the trigger seems to be > 2GB of scan data. This seems to just accomodate a 8.5x11" scan at 2400 DPI. However at 4800 DPI or 9600 DPI or 48-bit color, this can be triggered for a strip of film negatives.

This does not seem to be a process memory limit, as I can see the skanlite address space grow to > 6GB and > 3GB resident during successful scans. And as stated, ulimit is unlimited.

-- Bob

Comment 1 Christoph Feck 2018-06-27 16:35:51 UTC

Does the same issue happen if you use xsane? It might be a driver limitation ( using signed 32 bit numbers for data sizes).

Comment 2 Bob Mahar 2018-07-13 18:14:37 UTC

Same issue with xsane ( latest ) but different failure mode.   With xsane, I observe it building a pixmap temp file which corresponds to the size of the scan. The scan completes.  Once the scan completes, the xsane UI segfaults and disappears.   However the pixmap file is left behind.   This file is a consistent PNM formatted file and can be opened by GIMP 2.10 - it is a bunch of static, however I think this is because of the packing of the 48-bit samples.   ( You can see hints of structure and outlines and so on. ) 

So I am pretty sure the sane driver layer is acquiring a scan from the scanner and presenting this to the application.   However, again, if the temp file > 2GB, the xsane UI explodes.

The difference in behaviour is that xsane seems to acquire the whole image before crashing, whereas skanlite seems to be looking at the data as it is being scanned.

But yeah, similar outcomes, different failure modes.

Comment 3 Justin Zobel 2020-12-17 05:39:09 UTC

Thank you for the crash report.

As it has been a while since this was reported, can you please test and confirm if this issue is still occurring or if this bug report can be marked as resolved.

I have set the bug status to "needsinfo" pending your response, please change back to "reported" or "resolved/worksforme" when you respond, thank you.

Comment 4 Bug Janitor Service 2021-01-01 04:38:34 UTC

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

Comment 5 Bob Mahar 2021-01-05 01:47:09 UTC

This is still observable with latest version from todays openSUSE Tumbleweed.

Comment 6 Bob Mahar 2021-01-05 01:49:59 UTC

Changing status to REPORTED