Bonjour Gerard,
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 that information? > 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 [1] 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 [1]. Thanks, Paul [1] https://alioth.debian.org/tracker/?func=detail&atid=410366&aid=314019&group_id=30186 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20130213/0418dcd8/attachment.pgp>
