Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

SLRN & VMS (again)

4 views
Skip to first unread message

John E. Davis

unread,
Dec 10, 1996, 3:00:00 AM12/10/96
to

What TCP/IP implementation are you using? NETLIB? MULTINET?

About all I can think of is that slrn_exit_error is getting called
recursively when using VMS (e.g., by the cancel_read function in
clientlib.c. Hmmm... it appears that the cancel_read function should
not call slrn_exit_error at all; rather, it should call slrn_error and
simply return back to its caller. So, in clientlib.c, change the
cancel_read function to call slrn_error instead.)

To avoid the possibility or of slrn_exit_error being called
recursively, in slrn.c, replace slrn_exit_error by the following
TWO functions:

static void perform_cleanup (void)
{
if (Slrn_Groups_Dirty)
slrn_write_newsrc ();

if (Slrn_Server_Obj != NULL)
Slrn_Server_Obj->sv_close ();

#if SLRN_HAS_GROUPLENS
slrn_close_grouplens ();
#endif

lock_file (0);
}

void slrn_exit_error (char *fmt, ...)
{
va_list ap;
static int trying_to_exit;

if (trying_to_exit == 0)
{
trying_to_exit = 1;
slrn_set_display_state (0);
perform_cleanup ();
}

if (fmt != NULL)
{
fprintf (stderr, "slrn fatal error:\n");

va_start (ap, fmt);
vfprintf (stderr, fmt, ap);
va_end(ap);
}
putc ('\n', stderr);
exit (1);
}


--
John E. Davis Center for Space Research/AXAF Science Center
617-258-8119 MIT 37-662c, Cambridge, MA 02139
http://space.mit.edu/~davis

A. Andrew Brennan

unread,
Dec 11, 1996, 3:00:00 AM12/11/96
to

On 10 Dec 1996 20:33:03 GMT, John E. Davis <da...@space.mit.edu> wrote:
>What TCP/IP implementation are you using? NETLIB? MULTINET?

MultiNet V4.0 Rev A-X, AlphaServer 2000 5/300, OpenVMS AXP V6.2-1H3

>About all I can think of is that slrn_exit_error is getting called
>recursively when using VMS (e.g., by the cancel_read function in
>clientlib.c. Hmmm... it appears that the cancel_read function should
>not call slrn_exit_error at all; rather, it should call slrn_error and
>simply return back to its caller. So, in clientlib.c, change the
>cancel_read function to call slrn_error instead.)

Replaced these (the patches, etc.) but we still have a variant of
the problem. The most recent occurrence was as follows:

[a] read a local newsgroup,
[b] post a simple test note to the group,
[c] leave the article display,
[d] attempt to re-enter the group and "Selecting group..."
appears, but we never actually see the article display.

At this point, we're hung and I am forced to STOP/ID the process
from another window.

>To avoid the possibility or of slrn_exit_error being called
>recursively, in slrn.c, replace slrn_exit_error by the following
>TWO functions:

I'll ask the question that has me puzzled ... if it were calling
anything recursively, wouldn't there be some process activity or
some increase in CPU time?? I'm seeing absolutely nothing here.

andrew. (bre...@allegheny.edu)


Andrew Brennan

unread,
Dec 11, 1996, 3:00:00 AM12/11/96
to John E. Davis

[posted to USENET]

On Wed, 11 Dec 1996, John E. Davis wrote:

> > [a] read a local newsgroup,
> > [b] post a simple test note to the group,
> > [c] leave the article display,
> > [d] attempt to re-enter the group and "Selecting group..."
> > appears, but we never actually see the article display.
>

> Is there a time delay between steps b and d? That is, do you wait
> long enough for the server to timeout or does it occur immediately?

About 15 seconds ... the server definitely hasn't timed out as I can
check for open sockets (in other windows, of course) on both ends of
the connection. [I was just in the middle of sending you a note -
it happened again after I posted to news.software.readers ]

> It looks like it might be sitting some sort of wait state while
> trying to gather information from the server. The slrn unix code
> allows one to ^G to drop the connection without leaving the
> newsreader. Is there a way of killing the process from another window
> to force a traceback? Other than that, all I can suggest is that you
> put it in the debugger to find out where the problem is.

I may go with the debugger - we want to use SLRN here (we're replacing
ANU-News, a vile nasty slug that corrupts it's own newsrc files) but
these "hangs" have got to go.

> Another thing: the VMS version uses the TCP/IP code that is in the
> clientlib.c file whereas Unix and OS/2 use the code in sltcp.c. I
> would have ported that part to VMS but there does not seem to be a
> consistent VMS TCP/IP socket implementation; that's the reason that the
> clientlib.c code is such a mess.

Yup - although I ran into a problem by leaving SLRN_HAS_GROUPLENS as
the default, which defined SLRN_USE_SLTCP (the bottom of SLRNFEAT.H)
and made for an ugly compile pass. :^)

> Incidently, did you make this change to cancel_read in clientlib.c:

Yup.

andrew. (bre...@allegheny.edu)

John E. Davis

unread,
Dec 12, 1996, 3:00:00 AM12/12/96
to

On 11 Dec 96 23:52:22 GMT, A. Andrew Brennan <BRE...@allegheny.edu>

wrote:
> [a] read a local newsgroup,
> [b] post a simple test note to the group,
> [c] leave the article display,
> [d] attempt to re-enter the group and "Selecting group..."
> appears, but we never actually see the article display.

Is there a time delay between steps b and d? That is, do you wait
long enough for the server to timeout or does it occur immediately?

>>To avoid the possibility or of slrn_exit_error being called


>>recursively, in slrn.c, replace slrn_exit_error by the following
>>TWO functions:
>
> I'll ask the question that has me puzzled ... if it were calling
> anything recursively, wouldn't there be some process activity or
> some increase in CPU time?? I'm seeing absolutely nothing here.

It looks like it might be sitting some sort of wait state while


trying to gather information from the server. The slrn unix code
allows one to ^G to drop the connection without leaving the
newsreader. Is there a way of killing the process from another window
to force a traceback? Other than that, all I can suggest is that you
put it in the debugger to find out where the problem is.

Another thing: the VMS version uses the TCP/IP code that is in the


clientlib.c file whereas Unix and OS/2 use the code in sltcp.c. I
would have ported that part to VMS but there does not seem to be a
consistent VMS TCP/IP socket implementation; that's the reason that the
clientlib.c code is such a mess.

Incidently, did you make this change to cancel_read in clientlib.c:

static void cancel_read (int sig_unused)
{
#if 1
slrn_error ("CANCEL_READ: NNTP read failed.");
#else
slrn_exit_error("CANCEL_READ: NNTP read failed.");
#endif
}

Thanks,
--John

0 new messages