https://bugs.kde.org/show_bug.cgi?id=395391
Bug ID: 395391
Summary: Scan larger than about 2GB generate std::bad_alloc on
x64 server with >> 30GB free RAM
Product: Skanlite
Version: 2.1.0.1
Platform: openSUSE RPMs
OS: Linux
Status: UNCONFIRMED
Severity: crash
Priority: NOR
Component: general
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
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
--
You are receiving this mail because:
You are watching all bug changes.
