RE: Large table causes system meltdown - Too many images

Test case: http://pages.prodigy.net/chris_beall/Amaya/Manyimagecrash.html

Further information:

 - The problem has nothing to do with tables. (The test case contains none).
 - The problem has nothing to do with Reloading pages (but that's a
convenient way to reproduce it).  You can get the failure by simply going
from page to page, accumulating images as you go.
 - The problem has nothing to do with image SIZE.  (Changing to an image 1/4
the size of the one used in the above test case did not alter the failure
point.)

It appears that a brief description of the problem would be:
 Amaya has a limit on the total number of image fetches (occurences of the
<img> tag) it can process in a session.  The limit is somewhere around
1200-1400 (perhaps 1024?).  If this limit is exceeded, Amaya starts to write
over memory areas that it uses for other purposes.  If the limit is further
exceeded, Amaya writes over memory areas used by other tasks or the OS
(Windows 98).

Hopefully someone who knows the code will recognize something from the above
and know where the problem lies.

In addition to the above testcase, I was able to recreate the symptoms by
doing a search on Google images, then refreshing the page (showing 20 result
images) 36 times.

Is this likely to really occur?  Consider the developer who is browsing the
web to create links on a page under development.  It doesn't really take
long to pass over 1200 images this way.  And, since the consequences can be
damage to other running tasks on the system (at least on Windows 98...) I
believe this is a must-fix situation.

Chris Beall (with a sore mouse finger)

> -----Original Message-----
> From: www-amaya-request@w3.org [mailto:www-amaya-request@w3.org]On
> Behalf Of Chris Beall
> Sent: Friday, February 17, 2006 8:19 PM
> To: Chris Beall; Amaya users
> Subject: 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 [mailto:Chris_Beall@prodigy.net]
> > 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 http://www.w3.org/Style/CSS/Test/
> >       Confirm
> >
> >   When the page opens, click on the "Current" link near the top
> > of the page.  This takes you to
> > http://www.w3.org/Style/CSS/Test/CSS2.1/current/, 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 Sunday, 19 February 2006 03:31:43 UTC