Re: Large table causes system meltdown - Too many images

On Sunday 19 February 2006 04:28, Chris Beall wrote:
> 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).

Amaya doesn't impose a limit of total number of image it's able to fetch, but 
sometimes it could receive an http error because the delay to get the image 
is too long.
In this case it replaces the image by the alternate value, and if there is no 
alternate attribute (the page is not valid :-( ), it displays the <img> tag 
just to say that there is an image here.

On Windows 98, there is no memory protection and I'm not sure what happens 
when Amaya needs memory and the system is full.

> 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

-- 
     Irène.
-----
Irène Vatton                     INRIA Rhône-Alpes
INRIA                               ZIRST
e-mail: Irene.Vatton@inria.fr       655 avenue de l'Europe
Tel.: +33 4 76 61 53 61             Montbonnot
Fax:  +33 4 76 61 52 07             38334 Saint Ismier Cedex - France

Received on Thursday, 23 February 2006 16:22:50 UTC