lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LYNX-DEV Lynx271f crashes on VMS


From: Foteos Macrides
Subject: Re: LYNX-DEV Lynx271f crashes on VMS
Date: Mon, 15 Dec 1997 13:29:16 -0500 (EST)

address@hidden wrote:
>Some more tests, and problems....
>
>>address@hidden wrote:
>>>                      Problems with Lynx 271f - 2-dec-97
>>>                   ==================================
>>>
>>>     I attempted to build and install the current lynx271f, the build was
>>>>clean but attempting to use it produced some problems.
>>
>>      The traces are identical to those previously reported for the
>>devel code, so it presumeably is the same problem.
>>
>>
>>>(1) Crash on exit...
>>>     Start lynx then do 'q'
>>>
>>>Are you sure you want to quit? [Y]
>>>[...]
>>> 4468    1               exit(status);
>>
>>      That exit(status) invokes the VMSexit() handler in LYCurses.c.
>>Since it was a clean exit, the only thing it would do is make sure
>>stderr is not pointing to a file:
>>
>>    *stderr = LYOrigStderr;
>>
>>Try commenting out that line.
>
>       I tried this, exit is now clean.

        Try today's (1997-12-15) lynx271f.zip.  I moved that statement
to within the  if (LYTraceLogFP != NULL)  clause in cleanup() of LYClean.c.


>>>(2) Crash with Trace on...
>>>
>>>Start Lynx, press Crtl-T then attempt to follow an external link.
>>>
>>>Getting http://werple.net.au/~lions/header.htm
>>>
>>>%SYSTEM-F-ACCVIO, access violation, reason mask=00,
>>>     virtual address=00000050, PC=00149FCC, PSL=0BC00000
>>>%TRACE-F-TRACEBACK, symbolic stack dump follows
>>>module name     routine name                     line       rel PC    abs PC
>>>>
>>
>>      That fprintf() is protected against any of the strings being
>>NULL, so it similarly suggests that something funny is going on with
>>stderr redirection for VAXC.  Try invoking Lynx with the redirection
>>to a file turned off (-tlog).
>
>       I tried the following....
>
>       LYNX -trace         Sent the trace to the file then crashed.
>       LYNX -trace -tlog   Sent the trace to the screen then crashed.

        I can't explain that.  It's crashing on a fprintf() that should
be fully protected against bad arguments.  Sigh...


>       I have been using the new version and there are noticable
>improvements, particularly on some previously impossible forms. However
>there still seems to be a problem with cookies, (ie this has been there
>a long time but I had disabled cookies), go to a site with a cookie, allow
>the cookie, then press crtl-K
>
>[24;1H[7mGe[m[24;4H[7mting LYNXCOOKIE:/[m[K
>%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000050,
>       PC=00149FCC, PSL=0BC00000
>%TRACE-F-TRACEBACK, symbolic stack dump follows
>module name     routine name                     line       rel PC    abs PC
>
>                                                           00149FCC  00149FCC
>                                                           00147578  00147578
>LYCOOKIE        LYHandleCookies                 20144      000007DC  0007AF70
>[...]
>From LYcookie.lis
>
>20133    3                 /*
>20134    3                  *  Show the path, port, secure and discard 
>setting. - FM
>20135    3                  */
>20136    3                 if (co->path) {
>20137    4                     StrAllocCopy(path, co->path);
>20138    4                     LYEntify(&path, TRUE);
>20139    4                 } else {
>20140    4                     StrAllocCopy(path, "/");
>20141    4                 }
>20142    3                 sprintf(buf, "<DD>Path=%s\n<DD>Port: %i Secure: 
>%s\n",
>20143    3                              path, co->port,
>20144    3                              ((co->flags & COOKIE_FLAG_SECURE) ? 
>"YES" : "NO"));
>[...]

        I don't see anything wrong with that sprintf(), either, but in the
current lynx271f.zip it also indicates the Discard value based on the server's
Set-Cookie or Set-Cookie2 header.

        If the "utterly current" code still crashes, try adding /noopt
in build.com for the cc of LYCookie.c.  That's not a "solution", but
should indicate whether something in that module is too complicated and
tripping up the VAXC optimizer.  You might also try that for the cc of
HTTCP.c in libmake.com, and for HTTP.c  If any or a combination of those
get rid of the crashes, at least we know where to look for something that
needs to be simplified.

                                Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 address@hidden         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================

reply via email to

[Prev in Thread] Current Thread [Next in Thread]