Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!bellcore!ulysses!allegra!mit-eddie!genrad!panda!husc6!harvard!caip!ll-xn!cit-vax!elroy!smeagol!earle
From: earle@smeagol.UUCP (Greg Earle)
Newsgroups: net.bugs.4bsd,net.news.b
Subject: Limits on 4.2BSD lseek(2)?
Message-ID: <717@smeagol.UUCP>
Date: Tue, 13-May-86 23:23:45 EDT
Article-I.D.: smeagol.717
Posted: Tue May 13 23:23:45 1986
Date-Received: Thu, 15-May-86 23:42:09 EDT
Distribution: na
Organization: JPL, Pasadena CA
Lines: 51
Keywords: lseek  "Netnews 2.10.3 4.3bsd-beta 6/6/85"
Xref: mit-eddie net.bugs.4bsd:1883 net.news.b:1051

In the Netnews 2.10.3 4.3bsd-beta 6/6/85 distibution, there is a program
called article (written by Peter Honeyman, down!honey) that comes in
the `misc' directory.  This program will take an article message ID
(like 1052@ellie, 1424@lll-crg, etc.), look it up in the dbm version
of the news history file, and if it finds it, will print out the
first pathname it finds for the article (if it was cross-posted), by 
fetching the line containing the article ID from the history file.
Example:
	% /usr/lib/news/misc/article 150@hadron.UUCP
	/usr/spool/news/net/unix-wizards/XXXX (Your mileage may vary, here)
	%

The problem I have found, is that more often than not, the program will
blow up on a Bus Error.  This happens on a Sun 2-120 workstation, running
Sun OS 2.0 (4.2BSD based).  The cause of this Bus Error is an execution
of lseek(2).  A subroutine looks for the article ID in question, and returns
a datum that has a pointer to the entry in the history dbm file.
It then calls lseek(2) with this pointer dereferenced in order to get to 
that line in the history file.

Here is a snatch of the code (from ./misc/article.c in the distribution):

		...
                content = dofetch(*argv);
                if (content.dptr == 0) {
                        printf("%s: No such key\n", *argv);
                        continue;
                }
                if (lseek(fd, *(long *) content.dptr, 0) < 0)
                        continue;

So `content' gets the offset associated with argv, and lseek tries to
position to that spot.

I am finding that it retrieves some articles with no problem, but most of
them are gagging with the accompaning Bus Error.

Anyhow, this begs the basic question :
What are the limits on positioning in an lseek(2) under 4.2BSD?
What conditions are there, that allow successful completion of the call 
in some circumstances, and Bus Errors in (most) others?
This came about because my history (and .dbm) file is pretty big;
I made the assumption that the value returned in content.dptr was larger
than some cutoff value (Why should an lseek fail if the file has enough
bytes?  Arggghh ...), but I'm not sure ...

All ideas welcome ...
--

	Greg Earle		UUCP: sdcrdcf!smeagol!earle, attmail!earle
	JPL			ARPA: elroy!smeagol!earle@csvax.caltech.edu

My HAIRCUT is totally NON-TRADITIONAL!