Case 1: $ scanimage -L [sanei_wire] sanei_w_array: DECODE: maximum amount of allocated memory exceeded (limit: 1048576, new allocation: 567346072, total: 568394648 bytes) No scanners were identified. If you were expecting something different, check that the scanner is plugged in, turned on and detected by the sane-find-scanner tool (if appropriate). Please read the documentation which came with this software (README, FAQ, manpages). *** glibc detected *** double free or corruption (!prev): 0x000000000050a270 *** Aborted $ Case 2: # scanimage -L scanimage: stack smashing attack in function drvclose() Aborted # Apparently there is some sort of communication between the driver and the scanner (a plustek_pp), as I can see the scanner lamp turning on when the command is executed, but as you can see the scanner is not reported and scanning is out of the question too. Checked with sane-backends versions 1.0.15 and 1.0.16. The problem seems to be AMD64-specific, running the same versions built with -fstack-protector inside the 32-bit chroot on the same machine didn't cause any problems. Until the problem has been resolved in the code, it would be useful to have the offending compiler flag filtered out by the ebuild.
AMD64 team: Since I currently don't have access to my development box (and I am not sure when it will be restored) it would be nice if someone of you could fix this.
Silently filtered in -r2 (this should not affect many users). Marek, if you didn't yet do so it would be nice of you to report this problem upstream.
Okay, reported: https://alioth.debian.org/tracker/index.php? func=detail&aid=302195&group_id=30186&atid=410366
FYI, I have just worked this out and hopefully the maintainer of that particular back-end (the problem in my case was with the plustek_pp one) will fix it soon. See the upstream bug report at the URL posted earlier for details.
A patch fixing the problem and thus making it possible not to filter -fstack- protector on AMD64 has just been posted at the aforementioned upstream bug tracker. I have tested it, it works.
Looks like this was included upstream for 1.0.17.
