Henning Meier-Geinitz, Mon, 25 Sep 2000 :
[...]
> > It seems that the pnm backend (still) randomly crashes the graphical
> > frontends.
> > (activate "Three-Pass Simulation"->scan preview->deactivate
> > "Three-Pass Simulation"->activate "Grayify" and "Hand-Scanner
> > Simulation"->scan preview->crash)
>
> I can't reproduce this here (no crash) but this needn't mean anything.
>
> > IMHO the problem is a static variable which is used as a counter
> > for an array. This one "points" outside the array under several
> > circumstances.
>
> Are you talking about rgbleftover? Where exactly does the pnm backend crash?
>
> > Can someone test the attached patch (for pnm.c in Sane-1.0.3) and
> > confirm that it fixes the problem? (it does for me)
>
> I didn't look too close at the code but are you sure that moving the three
> variables inside the function will cure the segfaults? Isn't this just good
> luck?
> Could you locate the exact problem with gdb?
>
> While trying to reproduce "your" bug I found another one: pnm.c doesn't like
> changing the frame type and bit depth during runtime! If you load a 1 bit
> lineart pnm and than a 8 bit gray --> segfault (in the frontend preview). If
> you load a grayscale (8 bit) and then color (3*8 bit) -> segfault. pnm.c
> initializes params.dpth and ppm_type at the beginning but not after a change
> of the input image (at least not in every case).
>
Hi Henning,
I think I should have explained better, why I thought the patch
(if it is one at all) fixes the problem.
I ran into this problem when I did some tests with my frontend.
It seemed, that the problem was a call to sane_read() in the
pnm backend, which ignored the value in max_length.
Therefore the buffer allocated by the frontend is just to
small sometimes.
A search in the list archive revealed, that this problem was
first reported in 1999 (or 1998 ?) by Nick Lamb (IIRC).
I'm not sure, whether my patch was just good luck,
I thought I've tracked it down to the static variable
rgblength, which holds its value between calls to sane_read().
Setting this value to 0 at the beginning of sane_read() seemed
to cure the problem, because this leads to a recalculation of rgblength
and a reallocation of rgbbuf.
Finally I couldn't find a single reason, why this variable (and also
rgbbuf and rgbleftover) is static, so I moved it in sane_read().
(But it's, of course, also possible that this is complete nonsense;-)
The bt always looks like this (and didn't help much):
Program received signal SIGSEGV, Segmentation fault.
0x4001c101 in sane_pnm_read () at pnm.c:464
464 }
(gdb) bt
#0 0x4001c101 in sane_pnm_read () at pnm.c:464
#1 0x40017a06 in sane_dll_read () at dll.c:472
#2 0x40017ca9 in sane_read () at dll-s.c:34
#3 0x8050edd in input_available (data=0x20202621, source=606150947,
cond=639902240) at preview.c:536
#4 0x1d191819 in ?? ()
This isn't 100% reproduceable. You normally have to do several scans with
different settings until it crashes. However, with my patch, I can't reproduce
it at all :-) ... and with your patch the problem you described is gone too :-)
> This reveals another problem: xscanimage doesn't test if it gets too much
> data from the backend (at least in preview mode).
Are you sure? No frontend can handle the case, when a call to sane_read()
retrieves more data then specified in max_length.
bb
Michael
BTW
Is it really necessary that a frontend can handle scanning of a grayscale image
in three pass mode with a line number that isn't known a priori? I'm just
wondering whether such a hardware exists ...
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com
This archive was generated by hypermail 2b29 : Tue Sep 26 2000 - 10:27:12 PDT