32697 - demo#9 reconnect hack.

Status: VERIFIED FIXED

(Core :: Graphics: ImageLib, defect, P1)

Description

[pnunn]

Its baaack.
One animated image in 2 frames, requested image size the same
in both frames. Unload one frame. When timer kicks off new loop
for 2nd frame, get crash when trying to access 1st frame which is
dead and gone.  grep 'reconnect hack'.

Comment 1

[neeti]

Changing priority to P1.

Comment 2

[pnunn]

Attachment: fix for reconnect hack bug

Comment 3

[pnunn]

*** Bug 33788 has been marked as a duplicate of this bug. ***

Comment 4

[pnunn]

--------------------------------------------------------------------
Here's a short description of the bug:

Simplest example:  (see http://jazz/users/pnunn/publish/bugtest.html)

You have a page with 2 frames. Each frame has an animated image in it.
The animated image is the same image (and same size) in both frames.

If you unload the image in one of the frames and replace it with
another image, you often get a crash in ReconnectHack in nsImageGroup.
The crash occurs because the ImageGroup, known in ReconnectHack() as arg,
has been freed before it gets to this point.

There is a test for null on ImageGroup->mListenerRequest which fails
because mListenerRequest is garbage and non null.
-------------------------------------------------------------------
ok. Deep breath. Fasten your seat belts......
Here's a summary on why this bug occurs:

ReconnectHack() is called in GetURL() to reconnect with a stream you
already have. In ReconnectHack() if you have a Listener you can
update the Listener to the stream. If you don't have a listener, you
go back to the code that creates a new channel for the stream.


When the crash occurs, the ImageGroup was freed because GetURL used
a net_context that points to the ImageGroup that belonged to the
unloaded frame.  This occured because the animation callback is associated
with the image container. The image container belongs to both image
groups... it is in both frames.  The image container keeps a list of
each image request that uses its image. 

An image container has a clone of the net context of the requesting stream.
An image request has a clone of the net context of the requesting stream.
The image container has a list of the image requests (and thus a list of the
   net contexts from those image requests).
The image container also keeps a pointer to the last image request in the
list. 

The image container keeps its list of image request up to date, so the
when the animated image in one frame is unloaded, the request in the
image group that is unload is taken out of the image request list in 
the image container.

My fix is to issue the GetURL() request for each loop of the animation
through the net context of the last image request in the image container.


I have run this fix through purify and it does not create any new memleaks.

Comment 5

[pnunn]

checked in fix.
-P

Comment 6

[Eli Goldberg]

Verified fixed in 4.3.00 builds on all platforms. 

Specifically, displaying http://jazz/users/pnunn/publish/bugtest.html and 
clicking on the "click here to crash" push button doesn't trigger a crash.

pnunn, if there's more to the verification than that, please add your $.02.