RE: Large table causes system meltdown

Results of further investigation:

The original table is about 530 rows.  I tried reducing the number of rows,
deleting from the bottom, to see if I could find a point where the failure
stopped.  I could not.

There is, however, a corellation between the number of rows and the number
of Refresh cycles required to demonstrate a symptom.
  530 rows - two or three Refreshes
  about 60 rows - 20 Refreshes
  about 30 rows - 38 Refreshes
  20 rows - 57 Refreshes
  10 rows - 110 Refreshes
  5 rows - 201 Refreshes
  1 row - I did not get a failure in 300 Refreshes, but if the foregoing
progression holds true, it would have taken about 500.

The first symptom I observed (and I rebooted after seeing it to prevent
further excitement) was that the up and down triangles at the top and bottom
of the vertical scroll bar changed to digits ('5' or '6').

I tried multiple refreshes of several other large pages, one of which
contained a large table, but was unable to reproduce the symptom with any
page other than the original failing directory listing.

If time permits, I will try to isolate the problem further.

Question: Why would a refresh of a page have a result (in RAM usage) any
different from fetching it in the first place?  Why would going Back to a
previously-loaded page, then out on one of its links, then Back again also
result in differing RAM usage?

Chris Beall

> -----Original Message-----
> From: Chris Beall []
> Sent: Thursday, February 16, 2006 4:38 PM
> To: Amaya users
> Subject: Large table causes system meltdown
> Amaya 8.8.4 refresh, Windows 98 SE
> WARNING!: Executing the following scenario with Amaya can damage
> other running tasks on the system or the OS itself.  Reboot after
> running this scenario and before starting other tasks.  Be
> prepared to restore the test system.
> Scenario:
>   Open Amaya
>     Open document
>       Enter
>       Confirm
>   When the page opens, click on the "Current" link near the top
> of the page.  This takes you to
>, which is a
> directory listing (um, with an HTML 3.2 DOCTYPE...).  Note the
> status line "Reading 1K bytes".  Wait for this page to load
> completely.  Note the appearance of the page: 4 different icons
> in the left column, text is serif font, latin alphabet, only the
> column headers are boldfaced.
> This page consists almost entirely of a single table with 529 rows.
> Reload the same page.  Everything still look OK?  Reload the page
> again.  Repeat as necessary.
> If that doesn't get exciting enough, select the first test case,
> 'CSS 2.1 Test Suite: Comments', then, after that page has
> displayed, use the 'back' arrow to return to the test list page.
> Repeat.  For greater variety, select other test cases, then use
> the 'back' button.
> Symptoms I have seen:
>  - Icons on displayed page no longer appear.
>  - All text becomes boldfaced (sometimes only after screen is scrolled).
>  - Spacing between words becomes negative, so the last letter of
> one word overlaps the first letter of the next word.
>  - The arrows in the window scroll bars change to numbers.
>  - All text on displayed page becomes Greek letters.
>  - General Protection Fault.
>  - Amaya icon for active task on Windows toolbar disappears or
> changes to dark black.  Text becomes boldfaced.
>  - Status line shows "Reading 108K bytes" (not on Refresh; only
> on out-and-back scenario).
>  - Text in another running task on the same system (Outlook 2000)
> becomes invisible [I noticed this while trying to write this
> email while reproducing the problem].  When Outlook was closed
> and reopened, it reported problems with its 'folder shortcuts
> file'.  This indicates damage to some in-RAM component of Outlook
> that was written back to disk.
>  - System hang (occurred after Amaya had been closed and while
> opening an unrelated application).
> Analysis:
>  - No symptom is apparent when the large table is first loaded.
>  - Symptoms gradually become more dramatic and widespread as the
> page is reloaded.
> Conclusion:
>  - Loading of a large table causes data to be written outside the
> expected scope, damaging other Amaya data.  When Amaya uses the
> damaged data, its own functions begin to deteriorate.  In addition:
>    - Either Amaya passes bad data to system functions, which
> subsequently damage other running tasks or
>    - Bad data is written outside of the Amaya task space,
> damaging other running tasks.
> Discussion:
>   In order for this to happen, three things appear to be wrong:
>     1. Amaya has a fixed limit on the number of allowable table
> rows.  Since table size represents data passed by the user, and
> there is no limit defined in the HTML spec, Amaya should have no
> fixed limit.
>     2. When the limit is reached, Amaya fails to detect it and
> stores data beyond the allocated space.
>     3. The OS fails to either (or both):
>        3a. Prevent Amaya from storing data outside its task space.
>        3b. Validity check parameters being passed on system calls.
> Chris Beall

Received on Saturday, 18 February 2006 01:21:30 UTC