HP3000-L Archives

August 2000, Week 5

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Bill Cadier <[log in to unmask]>
Reply To:
Bill Cadier <[log in to unmask]>
Date:
Tue, 29 Aug 2000 09:59:19 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (88 lines)
Hi Stan,

When you reported this on 3000-L several months ago I had planned to take a
look at it because I was in the middle of some C development and this particular
problem was nailing me daily. I apologize for not doing that, I was side tracked
by some other crisis!

This morning I decided to have a look and serendipitously (an important component
in looking like a problem solving wiz :-) picked a file that reproduced this right off.
The problem is identical to that reported in 5003-273706 (1995) and which was
supposed to have been fixed. It appears that the fix never made it and I am
investigating this.

The technical details are this, the shell built-in 'tobyte' does this when '-t' (trim) is
used:

        if (trim) {
                while (buf[length-1] == '' '')
                        length--;
        }

The problem here is rather obvious. We loop until buf[lenth-1] is a blank which makes
a huge assumption. What makes this very hard to reproduce is that buf[-1] is not usually
a blank so the loop mercifully stops. The same file I instantly reproduced this with on 6.0
did not reproduce it in about 20 tries on 6.5.

The fix originally suggested in the SR was this:

        if (trim) {
                while ((length > 0) && (buf[length-1] == '' ''))
                        length--;
       }

That would work!

In defense of my colleagues in support they, as I, were fooled by the claim in the SR
that it was fixed and so assumed this to be some more esoteric problem. Problems
are peculiar in that they tend to stop occuring once you _try_ to solve them. When
you reported the problem several months ago I was seeing it daily. I stopped what
I was doing and actually _tried_ to make it happen so I could get a handle on it and...
it quit and never occured again for what seemed like weeks!

I've already begun looking into the fix to this and why it is not there. If you would like
to let whoever you speak to in the RC know this that would be fine. They can call
me if they need to. Also if a new SR is filed I will pick that up and follow thru on it.

Sorry for the confusion!

Best Regards,

Bill Cadier
HP/CSY
[log in to unmask]


>I just want to warn people that in some circumstances, using "tobyte"
>can result in the tobyte process running wild, creating an output
>file of many megabytes (and possibly up to 4 GB), eating CPU while it's
>happening.
>
>I reported this in 1999, and it was dropped (I can't find a Call ID).
>
>I reported it again in April of 2000 (Call ID 3100150578), and just
>noticed that it was closed *WITH NO EXPLANATION*.
>
>I've encountered the tobyte problem on 5.0, 5.5, 6.0, and (IIRC) 6.5.
>(I'm not 100% sure about 6.5).  It was generally on a tobyte
>of the form "tobyte -at /S/G/A foo.txt" (I.e., ASCII, truncate)
>And, it seems to happen about one time out of 200...
>but is generally not repeatable.
>
>(If anyone is encountering the problem, I have a sort-of-clone
>"tobyte" called "sstobyte", available for free at
>http://www.allegro.com/software/hp3000/allegro.html)
>
>
>
>Side comment: please...don't accept it if a call is closed with
>no explanation!
>
>Yes...I've submitted another call, complaining that the first call
>should not have been closed.
>
>--
>Stan Sieler                                           [log in to unmask]
>www.allegro.com/sieler/wanted/index.html          www.allegro.com/sieler
>

ATOM RSS1 RSS2