lynx-dev
[Top][All Lists]
Advanced

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

Re: LYNX-DEV weird crashes


From: Foteos Macrides
Subject: Re: LYNX-DEV weird crashes
Date: Sat, 17 May 1997 18:15:37 -0500 (EST)

Klaus Weide <address@hidden> wrote:
>On Sat, 17 May 1997, Larry W. Virden, x2487 wrote:
>
>> Thanks - I'll try.  However, for some weird reason it doesn't seem to
>> be consistent.
>
>If it is what I think it is, it would depend on whether you have visited
>pages with form fields earlier.

        Yes, a form must have been in the sequence, and your suggested
change will prevent Larry from dropping into the code where he's
crashing, but it's masking a longstanding bug in GridText.c, and he
could still crash in www_user_search().  I just fixed the longstanding
bug and updated fotemods.zip again:

* Fixed long-standing bug in display_page() of GridText.c.  When it
  was updating the links structures, it wasn't re-initializing the
  form element if the links structure is not for a form field. - FM


        However, as far as Larry is concerned, my bug fix still will
just mask whatever his real problem is with Lynx built using the
native solaris compiler instead of gcc.  To drop into that code,
the  links[i].form->value != NULL  check must have passed.  If it
was pointing to invalid memory due to the longstanding bug, he would
have crashed there.  If it was NULL, he wouldn't have dropped in.
Yet, when links[i].form->value then is used as the first argument
for LYno_attr_char_case_strstr(), it crashes as a bad pointer.
That doesn't make any sense at all, and thus implies a trashed
stack or registers due to some other, as yet unkown problem when
building with the native compiler (I can't get it to crash, even
with the longstanding bug, on Scott's solaris for the image built
with gcc).

        In the past, Larry has neglected to do a clean make when
upgrading.  Unless he's certain he did this time, I suggest he
do a clean make with his current, 1997-05-13 code, and see if
the problem still shows up when he tries to retrace whatever sequence
involving a form yielded the crash -- before he makes your suggested
change, or upgrades to the current fotemods.

        The same bug is in the devel code's check_for_target_in_links(),
and it has the longstanding re-initalization bug, so if Larry built the
devel code with the native compiler, and didn't do a clean make for that
upgrade, it presumeably is crash-prone too.

                                Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 address@hidden         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;

reply via email to

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