[sane-devel] [plustek] follow-up for Epson Perfection 1250/Photo 64-bit issue
paulepanter at users.sourceforge.net
Wed Feb 13 12:30:42 UTC 2013
Am Dienstag, den 12.02.2013, 20:53 +0100 schrieb contact adbdr:
> Gutenabend Gerhard und Paul,
a small spelling mistake: it is »Guten Abend«. ;-)
> Some answers after Gerhard Jaeger's mail:
> -It never occurs before the third scan, but sometimes only the fourth
> scan is bad.
> -The resolution does not seem to have any influence.
That is good to know.
> And an answer to Paul Menzel
> -I have to compress the log because the mail has to remain below 100k,
> otherwise it is rejected by the alioth mail handler
That is what I guess. Maybe it could be increased to 1 MB.
> Additional information:
> Setting in plustek.conf the binary in
> option altCalibration 0
> to 1
> has the result that the problem cannot be reproduced.
Wow. Nice find. Could you please update the bug report in Alioth with
> Scanning with valgrind active, as proposed by Paul Menzel, makes the
> process very slow,
That is expected as Valgrind checks all memory accesses.
> and also has the result that the problem cannot be reproduced.
Wow. I guess Valgrind somehow is able to fix the wrong accesses.
> G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind -v --tool=memcheck --leak-check=full --num-callers=50 --track-origins=yes --log-file=`date +%Y%m%d-%H%M%S`--simple-scan--valgrind.log simple-scan
> I selected two logs, the first with 'option altCalibration 1'
> the second with 'option altCalibration 0' in which case the problem is
> supposed to show up.
> But after gzip these are over 80k and the result is that a mail
> containing either the one or the other is rejected, so I need
> instructions as to how to transmit these.
Solving this issue by attaching the files to the Alioth bug entry
#314019  was a great idea.
> As the problem can't be reproduced while valgrind logs, I wonder whether
> there is any use in doing the same with an 32 bit OS.
I guess it is not necessary.
Just for the record for list or archive readers, there ware some
follow-ups on the Alioth report #314019 too .
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part
More information about the sane-devel