Closed Bug 229520 Opened 21 years ago Closed 21 years ago

crash while visiting www.gsmarena.com

Categories

(Core :: Graphics: ImageLib, defect)

Product:
Core
Component:
Graphics: ImageLib
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED DUPLICATE of bug 229652

People

(Reporter: vylu, Assigned: jdunn)

References

(
URL
)

Details

(Keywords: crash)

Attachments

(3 files)

Stack from crashing mozilla
27.32 KB, text/plain
Details
stacktrace for win2k
6.32 KB, text/plain
Details
The bad gif which causes the crash (in case the site corrects the problem)
9.89 KB, image/gif
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/20031226
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/20031226

Mozilla browser (nightly, 20031226) crashes when visiting http://www.gsmarena.com/

Reproducible: Always

Steps to Reproduce:
1.go to http://www.gsmarena.com
2.browse for a while in this site, try to open links and so on. 
3.browser crashes....

Actual Results:  
browser crashes

Expected Results:  
do not crashe
Linux 2003122607, no crash. I opened a lot of tabs from a lot of links from the
page for a long time.
I reproduced this on Linux too. Stack attached. This is with NO plugins
installed.
I can reproduce this even quicker with the flash plugin installed. Just go to a

flash site and keep reloading the page. It will crash always with the same
stack
shown. I believe this is a regression. Only started happening recently, but
can't pin it down.

Reporter can you change OS/Platform to All/All.
Browsing with 'epiphany' shows no problem (with or without flash
plugin installed).
OS: Windows 2000 → All
Hardware: PC → All
ok i can reproduce this on win2k (also my stacktrace is umm...see youself ;)
with these steps:
1. Go to http://www.gsmarena.com/
2. Click on Siemens under Manufacturers by interest
3. Click the back button
4. CRASH!

I have 4 different stacktraces, but they all crash in NTDLL
Attached file stacktrace for win2k — 
This are stacktrace produced on win2k with a current cvs trunk build
bz: any comments to this?
"Need a minimal testcase"  ;)
No crash on linux with 2003122309

The site doesn't use flash how far I can see it.
I think comment #2 is false and haven't to do with this bug.
First of all, anyone testing linux builds needs to say what sort of builds they
are testing; in particular the GTK versions.  Otherwise, the comments are pretty
useless.

That said, I'm more interested in the Windows crash as originally reported.
Comment 2 is not false and the stack provided is generated from a Linux Gtk2
build using gcc-3 and is 100% reproduceable. As i mentioned it has NOTHING to
do with the flash plugin as the problem happens with or without the plugin.
Here's a 100% reproduceable testcase. You may have to remove shockwave flash
plugin on Windows (again, i reiterate, this is not a flash plugin issue per-se).

Basically keep clicking randomly on the left hand menu of phones. Eventually
one of the adverts will be a x-shockwave flash plugin and you will get the
plugin helper dialog popup. Click 'Cancel' (i.e. don't install the plugin),
keep browsing he site and eventually it'll happen again (i.e. we come to
another shockwave advert) and the browser will crash.

The issue i believe is we still attempt to render to the plugin window area
even though we haven't set it up properly. The X error attached shows an
invalid window message which i can reproduce.

Ok, let's make it easier to reproduce. Go to 

http://www.shockwave.com/sw/home

You should get the plugin helper dialog popup assuming you don't have the 
plugin installed.

Click 'Cancel'
Click Reload page button 
Boom. Browser disappears.

100% reproduceable.
Mitch:

Does it also happen if you try the reloading with following page:
http://www.citykampf.de (the page uses often flash adverts).

Boris:

I'm working on a Debian unstable wich is daily updated.
libgtk: 1.2.10
libgtk: 2.2.4
Yup Alex, 100% reproduceable on that page too.
Hmmm, I use this page on a daily base (I love the game) but never crashed on the
page (with and the last day's without flash installed).

Will download newer nightly and try again.
I think i have the crasher (but i'm really not sure, since this site crashes
Mozilla also in a debug-build sometimes in css-style system *g*). After some
testing i came to this stacktrace with a debug build (i crashed here most of the
times). I first get this assertion before:
###!!! ASSERTION: OnDataAvailable implementation consumed no data: 'Error', file
 e:/mozilla/tree6/mozilla/netwerk/base/src/nsInputStreamPump.cpp, line 451

Stacktrace:
NTDLL! 778a144b()
nsDebugImpl::Assertion(nsDebugImpl * const 0x00269f60, const char * 0x0163c024,
const char * 0x0163c01c, const char * 0x0163bfdc, int 451) line 276
nsDebug::Assertion(const char * 0x0163c024, const char * 0x0163c01c, const char
* 0x0163bfdc, int 451) line 109
nsInputStreamPump::OnStateTransfer() line 451 + 26 bytes
nsInputStreamPump::OnInputStreamReady(nsInputStreamPump * const 0x04a9c1fc,
nsIAsyncInputStream * 0x048a260c) line 336 + 11 bytes
nsInputStreamReadyEvent::EventHandler(PLEvent * 0x04a68954) line 117
PL_HandleEvent(PLEvent * 0x04a68954) line 671 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00ff22a0) line 606 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x0012068a, unsigned int 49422, unsigned int 0,
long 16720544) line 1412 + 9 bytes
USER32! 77e02ca8()
USER32! 77e02dc5()
USER32! 77e02f0f()
nsAppShellService::Run(nsAppShellService * const 0x010abb90) line 484
(notice the NTDLL entrypoint is not the same as in the other stacktraces, but i
don't know how relevant is this here)
over to network
Component: Browser-General → Networking
bah sorry
Assignee: general → darin
QA Contact: general → benc
Mitch: I really think your bug is something else, since i (and opi, he told me
via IRC) don't crash on said pages and also stacktrace is different
Okey dokey. Will open another bug for it. Thanks. Just that i first saw it
on the reporters mentioned URL.
bug 223302 might be related
bz: maybe i should test the patch from that bug?
Frank, sure.  And if you get a reproducible style system crash, file it and CC me.

Alexander, what matters is what GTK version Mozilla is using (1 or 2), not what
you have installed on your system.
That patch from Bug 223302 does nothing at all :/
debian unstable uses gtk2 for their mozilla builds (at least for the mozilla
package, presumably also for mozilla-snapshot)
The mozilla nightly builds are gtk 1 builds, so I think they will use the gtk 1
library. Also my own mozilla de-AT builds are build against gtk 1.

And I thought there are no official nightly's with gtk2 at the moment.
There are various gtk2 nightlies, actually (the RPMs, xft builds, etc, etc). 
Just make sure that about:buildconfig says the right thing.  ;)
Boris:

I think the so called "nightly builds" are the official one from
http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest-trunk/ and I think
they are build every time the same configuration. If someone use an other build
(or rpm etc.) it won't be the so called "nightly build" (I asked many time on
irc how to add special chars or numbers to the build id, so we have different
build id's for different distributions).


But if you need:
Configure arguments
--disable-tests --enable-extensions=default,irc --without-system-nspr
--without-system-jpeg --without-system-zlib --without-system-png
--without-system-mng --disable-debug --enable-optimize=-O2 --enable-crypto
--enable-strip
*** Bug 230670 has been marked as a duplicate of this bug. ***
Actually it's a bad gif image which is causing the crash.
http://www.no-air-time.com/images/bs_cti_y.gif

After narrowing the page down (it was framed) to news2.php3, I downloaded the
source.
I had stripped all the .gif and .jpg, replacing them with .xgif and .xjpg
respectively. This stopped the crashing. Which meant (to me) there was a bad
image. I then added each one back one by one until the crash occurred.

I stopped at that gif (which was producing the crash).
Attached the gif from the site so it would still be on file should the site
correct the problem.
Bad gifs would be imagelib.
Assignee: darin → jdunn
Component: Networking → ImageLib
Possibly a duplicate of bug 229652.
Depends on: 229652
With the patch from bug 229652 this gif is handled fine by both linux and win32.
Marking duplicate.

*** This bug has been marked as a duplicate of 229652 ***
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: