Gif Painting Problem - 1.8 branch

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Gif Painting Problem - 1.8 branch

Felix Miata-2
http://mrmazda.no-ip.com/SS/Mozilla/moz-gif-paint.html has screenshots,
the description of the painting problem in the current branch, and the
problem gif . Anyone seen this before, and/or know an existing bug about
it? I've only been able to produce it in the current OS/2 session as the
only URL in the 17th tab history of 19 total tabs open, plus a CZ window
with 15 tabs open. WFM in Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.8.1b1) Gecko/20060717 SeaMonkey/1.1a and Mozilla/5.0 (Windows; U;
Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060717 SeaMonkey/1.1a .

Posted from NN 4.61, as SeaMonkey still won't permit crossposting:
https://bugzilla.mozilla.org/show_bug.cgi?id=230899
--
"If you confess with your mouth, 'Jesus is Lord', and believe in
your heart that God raised him from the dead, you will be saved."
                                                Romans 3:23 NIV

 Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://mrmazda.no-ip.com/
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Gif Painting Problem - 1.8 branch

Felix Miata-2
Steve Wendt wrote:

> Felix Miata wrote:
 
> > http://mrmazda.no-ip.com/SS/Mozilla/moz-gif-paint.html has screenshots,
> > the description of the painting problem in the current branch, and the
> > problem gif . Anyone seen this before,
 
> Sure, I've seen such things after running the browser for a while,
> displaying lots of images.  I think it's a shared memory problem.

In all the years and long uptimes (up to 5 days or more) I've run Moz on
OS/2 I can't remember this happening before. Since posting I've seen
more images apparently randomly do this or not, and not just GIFs.
--
"If you confess with your mouth, 'Jesus is Lord', and believe in
your heart that God raised him from the dead, you will be saved."
                                                Romans 3:23 NIV

 Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://mrmazda.no-ip.com/
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Gif Painting Problem - 1.8 branch

Felix Miata-2
In reply to this post by Felix Miata-2
On 06/07/22 07:32 (GMT-0500) Peter Weilbacher apparently typed:

> On Wed, 19 Jul 2006 18:20:38 UTC, Felix Miata wrote:
 
>> http://mrmazda.no-ip.com/SS/Mozilla/moz-gif-paint.html has screenshots,
>> the description of the painting problem in the current branch, and the
>> problem gif . Anyone seen this before, and/or know an existing bug about
>> it? I've only been able to produce it in the current OS/2 session as the
>> only URL in the 17th tab history of 19 total tabs open, plus a CZ window
>> with 15 tabs open.
 
> Hmm, so to reproduce I have to open all those tabs, probably with the
> same URLs in all of them? That's hard and could really point to a shared
> RAM issue as Steve mentioned... I just tried with a freshly built 1.8
> OS/2 SeaMonkey and some of the pages I visit daily, but it didn't occur.
> Neither with "Resize large images" nor without. Well, I will keep my
> eyes open, in case it appears here after extended surfing.

I have a different scenario that might be easier to repro. First, only
large images are necessary, not only gifs. Large uptime seems to be
required, along with consequent large RAM usage. My last two crashes
happened approximately the same. Here's what I can recall about today's:

1-Crash was immediately precipitated by attempting to open
http://mrmazda.no-ip.com/SS/desktop-a-865-1792x1344x144.png in a new
tab.
2-RAM freed as result of crash: 285M
3-Uptime at crash: 45.5 hours
4-Heavy usage while up, including mail, news, 14 CZ tabs, and lots of
browser tabs, both regular and https
5-Bad image painting behavior noted shortly before crash:
http://sperling.com/dave2.png had been loaded and properly some time
before, but when I returned to it, the viewport was entirely blank, and
reload didn't help. What worked was as described in my first post in
this thread, sufficiently reducing the viewport size.

https://bugzilla.mozilla.org/show_bug.cgi?id=197263#c21 checkin seems to
be about the time after which this later scenario began happening. I
can't really date it, because it produces nothing in popuplog.os2, and
it took me a while to recoginize the repro sequence. It may have nothing
to do with why I started this thread.

Courtesy of nearly 3 year old
https://bugzilla.mozilla.org/show_bug.cgi?id=230899 this has been posted
with Netscape 4.
--
"Wisdom is supreme; therefore get wisdom. Though it cost all you
have, get understanding. Esteem her, and she will exalt you;
embrace her, and she will honor you." Proverbs 4:7-8 NIV

 Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://mrmazda.no-ip.com/
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Gif Painting Problem - 1.8 branch

Ilya Zakharevich
[A complimentary Cc of this posting was sent to
Felix Miata
<[hidden email]>], who wrote in article <[hidden email]>:

> 1-Crash was immediately precipitated by attempting to open
> http://mrmazda.no-ip.com/SS/desktop-a-865-1792x1344x144.png in a new
> tab.
> 2-RAM freed as result of crash: 285M
> 3-Uptime at crash: 45.5 hours
> 4-Heavy usage while up, including mail, news, 14 CZ tabs, and lots of
> browser tabs, both regular and https
> 5-Bad image painting behavior noted shortly before crash:
> http://sperling.com/dave2.png had been loaded and properly some time
> before, but when I returned to it, the viewport was entirely blank, and
> reload didn't help. What worked was as described in my first post in
> this thread, sufficiently reducing the viewport size.

This behaviour looks very similar to the testcase I provided about a
month ago to Peter (can't provide the link publicly).  He claims that
the reason for my testcase crash is fixed in his latest release of FF
for OS/2 (all except "blank painting when remaining memory is low").

Can it be fixed *now*?

Thanks,
Ilya [Fup to mozilla.dev.ports.os2]
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout