Re:

I wrote:

> : I reported it again in April of 2000 (Call ID 3100150578), and just
> : noticed that it was closed *WITH NO EXPLANATION*.
> : Side comment: please...don't accept it if a call is closed with
> : no explanation!

Several HP people were kind enough to write me saying something
to the effect:

   > It says that it couldn't be duplicated, in March 13.

or:

   > there's a response from the HP ESC in the call ID.

So...I went back and checked...no response *VISIBLE TO ME*.

I suspect that what happened is that the engineer who entered the
response failed to mark it "customer visible", so I couldn't see it.


Technical note...

Bill Cadier wrote me about the probable problem.  He sure seems to
have found the bug, although the full analysis is a bit more complicated.

A loop like:

        while (buf[length-1] == '' '')
           length--;

will not loop forever unless "length" is a 16-bit counter.

(If "length" is 16 bit counter, and if a blank is not found in buf
or in the first 64K bytes below buf, then that 64 KB bytes will be
searched over and over.)

If "length" is a 32-bit counter, and a blank isn't found anywhere (which
is extremely unlikely), then the process will abort when buf [length]
indexes to an inaccessible page below the stack.  On a typical run of
tobyte, the "abort" point is around 53000 bytes...pretty small number!

However, I'd seen both heavy CPU usage, and "disk eating" (the output
file growing ever larger)...not just a CPU loop.

So, I suspect that what happens is something more complicated:

   the "while" loop terminates, with a small negative value for length.

   the subsequent code is something like:

       p = &buf [0];

       while (length--)
          do something with *p, increment p.

depending upon what's done with the data (e.g., copying to an
in-stack buffer, or a malloc'd buffer, or to disk), different
things could result (e.g., stack corruption, infinite CPU loops,
disk consumption loops, or a combination ... aren't computers
wonderful? :)

Well, I could conjecture all day ... but without closer examination
and/or access to source code, I think I'm just going to back to work :)


The summary is: perhaps the HP ESC software should not make it possible
to make entries invisible to customers ... or at least, make it much
harder to mark them invisible!

--
Stan Sieler                                           [log in to unmask]
www.allegro.com/sieler/wanted/index.html          www.allegro.com/sieler