[news.software.b] possible vn bug?

jra@jc3b21.UUCP (Jay R. Ashworth) (12/23/87)

While bopping along in vn, reading the news, (Thanks, bobm) I occasionally 
get shot down by what appears to be a bug in the program.  To wit:
If I attempt to read an article with a header line which is continued,
e.g.:

Keywords: This is a test.
	  This is only a test.

the program bombs, after showing all the header lines (I have header
display toggled off), with a floating exception, core dumped.  I note
that when this happens, there is evident, intermixed with the headers,
the line

Lines: 0

.  Since the "core" doesn't "dump" until the end of the screen, could
this problem be triggered by the percent left code in the builtin
pager?  The bug also appears to slightly mung the .newsrc table, as
after it happens, I get articles back to read again.

Any help will be appreciated.  Also, does anybody know if vn can track
cross-posted articles, so I don't have to read the dratted things more
than once?

Later,
-- jra

-- 
Jay R. Ashworth	---+--- The Great Ashworth & ------------+...!uunet!codas!pdn!
10974 111th St. N. |        Petrillo Production Company  |          jc3b21!jra
Seminole FL 34648  +-------------------------------------+-----------+---------
(813) 397-1859 ----+--- Tampa Bay's Smallest Video Production House -+ :-) !$

wpl@burdvax.PRC.Unisys.COM (William P Loftus) (12/24/87)

From article <222@jc3b21.UUCP>, by jra@jc3b21.UUCP (Jay R. Ashworth):
> While bopping along in vn, reading the news, (Thanks, bobm) I occasionally 
> get shot down by what appears to be a bug in the program.  To wit:
> If I attempt to read an article with a header line which is continued,
> e.g.:
> 
> Keywords: This is a test.
> 	  This is only a test.
> 
> the program bombs, after showing all the header lines (I have header
> display toggled off), with a floating exception, core dumped.  I note
> that when this happens, there is evident, intermixed with the headers,
> the line
> 
> Lines: 0
> 

I had fixed this bug in the previous version of vn (not the current release).
I guess the fix never made it into the developers codes (although, I did send
him a fix for the bug.).
The following text describes how the bug was fixed in the previous version of vn
NOT the current version.
--
I had a problem with vn.  Once in a while, vn would crash with a floating
point exception (divide by zero).  I tracked to bug to the following lines
of code in reader.c.

	/* for conditional is abnormal - expected exit is break */
	for (count = 0; count < HDR_LINES && fgets(buf,RECLEN-1,Fpread) != NULL; ++count)
	{

		/* reset position and bail out at first non-header line */
		if (index(buf,':') == NULL)
		{
			pos = ftell(Fpread);
			pos -= strlen(buf);
			fseek (Fpread,pos,0);
			break;
		}


Vn had thought the header ended when there was a line with no ':'. This is
a false assumption (I think), a header ends when there is a line that doesn't
begin with ' ' or '\t' and has no embedded ':'.
Below is the fix to the above code.


	/* for conditional is abnormal - expected exit is break */
	for (count = 0; count < HDR_LINES && fgets(buf,RECLEN-1,Fpread) != NULL; ++count)
	{

		/* reset position and bail out at first non-header line */
		if (index(buf,':') == NULL)
		{
                        if ((buf[0] != '\t') && (buf[0] != ' ')) {
				pos = ftell(Fpread);
				pos -= strlen(buf);
				fseek (Fpread,pos,0);
				break;
                        }
		}


-- 
William P Loftus			UUCP:   wpl@burdvax.UUCP
Unisys/Paoli Research Center		ARPA: 	wpl@burdvax.prc.unisys.com
PO Box 517				BITNET: 202527899@VUVAXCOM
Paoli, PA 19301                         215-648-7222 (work) 215-354-0614 (home)

eb@soliloquy.uucp (Ed Blackmond) (12/25/87)

In article <222@jc3b21.UUCP>, jra@jc3b21.UUCP (Jay R. Ashworth) writes:
> While bopping along in vn, reading the news, (Thanks, bobm) I occasionally 
> get shot down by what appears to be a bug in the program.
>  ...
> .  Since the "core" doesn't "dump" until the end of the screen, could
> this problem be triggered by the percent left code in the builtin
> pager?  The bug also appears to slightly mung the .newsrc table, as
> after it happens, I get articles back to read again.
> 
I got this too and as you suspect it is related to the
percent calculation at the end of the page.  I just hacked
it to not do the division if it thinks there are zero lines
in the article.  This gives bogus percentages for these
articles but I don't really care.

The problem is in the function readline() in the file
reader.c  Here is the code I use now (sorry I forgot to
check it into RCS before hacking on it so I don't have a
diff):
---
reader.c 196 - 205
                       /*
                        ** calculation is truncated rather than rounded,
                        ** so we shouldn't get "100%".  Subtract 2 for
                        ** 1 line lookahead and empty line at beginning
                        ** of article.
                        */
                        if (Headflag || artlin == 0)
                                percent = ((Rlines-2)*100)/(artlin+Hlines);
                        else
                                percent = ((Rlines-Hlines-2)*100)/artlin;
---
I added the "|| artlin == 0" test.
-- 

Ed Blackmond		Disclaimer: The above opinions are those of the
Sun Microsystems	     author and should be considered the gospel
sun!soliloquy!eb	     truth.  ( cat Mathew/5:48 | sed s/you/I/ )

bobm@rtech.UUCP (Bob McQueer) (12/27/87)

This bug was much-discussed after surfacing about a year ago.  The fix was
immediately inserted into the sources I keep.  The stuff I recently issued
in alt.sources is the first "official" reissue since then.  It should not
display this particular bug (I just rechecked the sources to make sure, and
found buf[0] == '\n', not index(buf,':') == NULL, as well as a check to
prevent the divide by zero in the instance of there being no "Lines" line).

Murphy's law has struck, though.  I was happily running my new version for
months before posting it, and discovered a bug similar to this after posting,
although this one really shouldn't show up as much.  A badly scrozzled article
which has no "From", "Path" or "Reply-to" line will make it die when you try
to read the article.  I'll post a fix once I get other feedback from the
new posting.  It will only bite people curious enough to try to read articles
displayed with titles like "? ? ~ ?" because vn couldn't find a subject line,
etc., like me.  Here, at least, we haven't been getting such articles
regularly.  The one I saw was a great novelty.  The article in question had
obviously been truncated, so that the NNTP server thought the first few lines
of text were headers, followed by the last paragraph or so of the article.

BTW, I might as well solicit an opinion.  I've been changing vn to use NNTP,
and came across a little wrinkle that ties in with recent discussion.  In the
non-NNTP version, it posts followups by handing off to "inews", and letting
inews create a "From" line, which gets to be the user.  I found that if I
hand off to the NNTP'ed version of inews without a "From" line, it winds up
being from "News System", or some such thing.  I've got a configuration
ifdef in there now, to control whether:

	1 - a "From:" line is created, and placed in the user's edit file
		along with the other header lines.  Convenient, but it
		could be viewed as encouraging userid forgery.  That's how
		I have ours configured, and my "From:" line is sitting at
		the top of this very file.  I refrained from editting it.

	2 - a "From:" line is prepended to the user's stuff, thereby making
		any "From:" line the user inserted futile.

There could obviously also be a technique 2a of prepending only if the user
hasn't inserted one, which would require a bit more work.  Question:  Should
it be configurable in the first place?  If so, which should be the default?
If not, which should simply be the way things are done?
{amdahl, sun, mtxinu, hoptoad, cpsc6a}!rtech!bobm