RE: Large table causes system meltdown - Too many images

> -----Original Message-----
> From: www-amaya-request@w3.org [mailto:www-amaya-request@w3.org]On
> Behalf Of Irene Vatton
> Sent: Thursday, February 23, 2006 11:21 AM
> To: Chris Beall
> Cc: Amaya users
> Subject: 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.

Understood, but that's not the case here, as most of my testing was done
with all files on my hard drive.  My original test case did include alt=
attributes, but I removed them as part of seeking a minimum failing case.
Their presence did not alter the symptoms.

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

I'm not familiar with the specifics of Windows 98, but most memory systems
work pretty much the same way:

1. Application requests X bytes of memory
2. OS allocates all of the requested memory and returns a pointer to it to
the application.
     or
2a. OS allocates less memory than requested and returns both a pointer to
the memory and the length that it was able to allocate.
     or
2c. OS is unable to provide the memory and returns a failure Return Code to
the application.
3. The application deals with the result, which means:
 - The application must check for and be prepared to deal with a rejection
of its request.
 - The application must check for and be prepared to deal with a reduced
allocation of memory (if the OS supports that mode of operation).
 - The application must manage the usage of the memory it has been given,
i.e. must not access outside its bounds nor use the same piece of it for two
things.  [Good OSs will trap attempts to access outside of allocated memory
(and usually blow the application out of the water); Windows 98 is not one
of those...]

But regardless of whether the OS catches violations, it is the
responsibility of the application to stay within its allocated memory.  It
appears that Amaya is not doing that in the case described.

I would expect to see different symptoms, but an equally dramatic failure,
on any OS.  Can someone on another platform replicate the problem, using the
test case shown above?  To avoid the http-error scenario, you can copy the
test page and the image it uses ('back.gif') to a local drive.  Just open
the page in Amaya and then Reload the page 20 or so times.

Chris Beall

> > 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)

(snip earlier descriptions of problem scenario)
>
>

Received on Thursday, 23 February 2006 21:46:22 UTC