[hylafax-users] Bug in EXPAND1D

[Joerg Anders <J.Anders@Informatik.TU-Chemnitz.DE>]

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