lynx-dev Help solicited in shooting NASTY intermittent bug (was: [dev17] patch with new TEXTAREA commands, etc.)

[Kim DeVaughn]

[well *that* took long enough to propagate ... near 17 *hours*]

Anyway ...

On Wed, Feb 24, 1999, I said:
|
| c. Isolate and fix a bloody nasty intermittent bug that exists in this (as
|    well as in the earlier versions of the) TEXTAREA editing-related code.
|
|    I'll describe this pest in a seperate post, as I'll be damned if I can
|    find it.  It only happens if you're numbering links *and* form anchors,
|    and then intermittently on only one page that I've come across.  There
|    is a crude trap in the code for this SOB, but nastiness is still likely
|    to happen.  More on this later.

OK ... I am nearing my wit's end trying to nail this sucker.  I have
inserted innumerable trace and printf statements, stepped thru a ton
of code with gdb, put gdb watchpoints all over the place, and tried
a number of voodoo incantations to assist in finding this bug ... all
to no avail.  I cannot "see" it, and I cannot "find" it.

I have only run into this on one imdb (Internet Movie DataBase) page,
amd then only about half the time I bring it up.  When the failure is
happening, it happens every time I bring up the page for several hours
on end; when it is not happening, it behaves OK for several hours on
end.  I'll describe how to get to the page, below.

When it is in a "failing time period", if I grab a copy of the source
and use it locally, *that* copy does not fail.

It only happens if the o(ption) to number both links *and* form anchors
is turned on.

It gets detected in the function  update_subsequent_anchors()  by a
hang condition (infinite loop).  Some of the time the current anchor
value, and the  anchor->next  value have somehow become identical.  At
other times, the  anchor->number  variable has taken on the value of
some anchor pointer itself (normally, this var should be in the 1-nnn
range, where nnn is ~200, or thereabouts).

Clearly, the TextAnchor list is getting stepped on someplace, but not
in a completely consistant fashion.

I've put a trap in the code to detect these conditions, but by then the
damage has been done, and lynx will likely crash and burn badly if a
QUIT/ABORT command is attempted.

It is who/where the list is getting stepped on, that I have been unable
to find.

I've dumped out the entire list of TextAnchors just before the block of
code where the hang occurs, and the list looks OK (near as I can tell)
going into it, when the page is in a "failing time period", so it *seems*
that things are alright as far as the original rendering is concerned
(even though there is obviously *some* sort of data dependency, WRT
"failing time period" vs. "not-failing time period").

I could *really* use some help in isolating the problem.


Here is the easiest way to create the failure (when it's in a "failing
time period"), assuming that the latest patch has been applied, and that
link and form field numbering is on:

 1. Go to http://www.imdb.com/

 2. Enter the name of your favorite actress/actor in the "Search for"
    field (be sure to activate the "Name" button), then "GO".

 3. Scroll down to the "Add/correct data for this person" submit link,
    near the bottom of the page, and activate it.

 [If you have not previously "signed up" at the IMDB to allow you to
  send in "updates", you will need to fill out their form, and accept
  their cookies.  Persistent cookies work nicely with them to keep
  your user/password for subsequent "update submits", BTW.]

 4. Now on their "IMDb title info addition" page, scroll down near the
    bottom and select the:

     [112][X] Add information on awards/nominations received by this person
     unrelated to a movie/tv series (awards relating to titles MUST be
     added via the title additions form)s.

    checkbox field.

 5. Cursor down a couple links to the "[114]Add information on the above"
    submit field, and activate it.

 6. You should now be on the "IMDb name info addition" page.  Scroll down
    to the first TEXTAREA, then cursor down to the *last* line in that
    TEXTAREA.

 7. Hit ENTER (which should add a new TEXTAREA line, given the new patch).
    That one should work OK.

 8. Hit ENTER again.  That one should cause the hang (if it is a "failing
    time period").  If there's no failure, try again some hours later.

Any profound insights from this point on, gdb traces, etc, would be MOST
appreciated.

Note that in the many other IMDB pages that I've tried, as well as my own
set of test pages, I've not been able to cause this failure.

I have been able to recreate the failure on this particular page using
EDITTEXTAREA (instead of the ENTER/AUTOGROW feature), but then the number
of edited lines entered becomes a factor as well.

It almost seems as if the anchor list is getting stepped on asynchronously
by some sort of interrupt, but it's probably just me missing something
obscure, like a cast I just cannot see, or some such.

But why it should be *so* "consistently intermittent", as well as being
inconsistent in the actual struct element that gets corrupted, I have NO
idea ...


Thanks for any help in shooting this puppy ...!

/kim