[hylafax-users] Re: Bug in EXPAND1D

["Bernd Proissl" <news@proissl.de>]

Joerg, this is a known issue:

http://www.hylafax.org/patches/tiff-3.5-interfaces.patch
http://www.hylafax.org/archive/2000-06/msg00208.php
http://www.hylafax.org/archive/2000-05/msg00218.php
http://www.hylafax.org/archive/2000-05/msg00210.php

old/outdated:
http://www.hylafax.org/archive/2000-05/msg00193.php

Bernd

> -----Original Message-----
> From: hylafax-users-bounce@hylafax.org
> [mailto:hylafax-users-bounce@hylafax.org]On Behalf Of Joerg Anders
> Sent: Thursday, July 13, 2000 8:08 PM
> To: hylafax-devel@hylafax.org; hylafax-users@hylafax.org
> Subject: [hylafax-users] Bug in EXPAND1D
>
>
>
> There is a bug in hylafax-v4.0pl2 in G3Decoder.c++ near line 272
> in method "G3Decoder::decodeRow".
>
> I don't know exactly the reason. The the bug occurs if the option "-n"
> isn't set, i.e. there shell be a cover page. In this case
> the "faxq" hangs.
>
> I inserted a test in method faxQueueApp.c++
> method MemoryDecoder::scanPageForBlanks near line 852:
>
>   for (;;) {
>     fprintf(mylogf, "scanPageForBlanks(1b)\n"); fflush(mylogf);
>     (void) decodeRow(NULL, rowpixels);
>     if (isBlank(lastRuns(), rowpixels)) {
>           endOfPage = bp;                 // include one blank row
>           nblanks = 0;
>           do {
>               fprintf(mylogf, "scanPageForBlanks(1c)nblanks =
> %d\n", nblanks); fflush(mylogf);
>               nblanks++;
>               (void) decodeRow(NULL, rowpixels);
>               fprintf(mylogf, "scanPageForBlanks(1ccc)\n");
> fflush(mylogf);
>           } while (isBlank(lastRuns(), rowpixels));
>           fprintf(mylogf, "scanPageForBlanks(1d)\n"); fflush(mylogf);
>     }
>     fprintf(mylogf, "scanPageForBlanks(1e)\n"); fflush(mylogf);
>   }
>
> wherby "mylogf" is a previously opend personally logfile.
>
> If "nblanks" reaches the value 179 the logfile shows:
>
> scanPageForBlanks(1c)nblanks = 179
> scanPageForBlanks(1ccc)
> scanPageForBlanks(1c)nblanks = 180
>
> That is in case of 180th blank the "decodeRow" doesn't return.
>
> I inserted in "G3Decoder.c++" near  line 272 in method
> "G3Decoder::decodeRow":
>
>       } else {
>   #define badlength(a0,lastx) do {                        \
>       nullrow = (a0 == 0);                                \
>       if (nullrow && ++RTCrun == 6 && RTCrow == -1)       \
>           RTCrow = rowref-6;                              \
>       badPixelCount("1D", a0, lastx);                     \
>       rowgood = FALSE;                                    \
>   } while (0)
>           fprintf(mylogf, "decodeRow(7b)\n");fflush(mylogf);
>           EXPAND1D(Nop1d);
>           fprintf(mylogf, "decodeRow(7c)\n");fflush(mylogf);
>       Nop1d:;
>   #undef  badlength
>
> The output after scanPageForBlanks(1c)nblanks = 180 is:
>
>   decodeRow(7b)
>
> Therfore I assume the EXPAND1D hangs. To trace EXPAND1D
> is too complicated to me.
>
> --
>
> Because it has to do with TIFF:  "ldd faxq" gives:
>
>      libtiff.so.3 => /usr/lib/libtiff.so.3 (0x40015000)
>
> Is there a known bug in some libtiff?
>
> Or has somebody an idea what I could test next?
>
> I use S.u.S.E-Linux-6.4. First I used the RPM from S.u.S.E-6.4
> distribution. It was hylafax-41beta2. Then I downloaded  "hylafax-v4.0pl2"
> and translated the source with gcc version 2.95.2 19991024 (release).
>
> The effect is the same. If I don't set the "-n" option the
> "faxq" hangs!
>
> If I use the option -n the logfile alwasy shows
>
>    decodeRow(7b)
>
> followd by
>
>   decodeRow(7c)
>
> as expected.
>
> ???
>
> --
> J.Anders, Chemnitz, GERMANY (ja@informatik.tu-chemnitz.de)
>
>
>
>
> ____________________ HylaFAX(tm) Users Mailing List
> _______________________
>  To unsub: mail -s unsubscribe hylafax-users-request@hylafax.org
> < /dev/null
>



____________________ HylaFAX(tm) Users Mailing List _______________________
 To unsub: mail -s unsubscribe hylafax-users-request@hylafax.org < /dev/null