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.
Created attachment 138034 [details] Stack from crashing mozilla 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).
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
Created attachment 138035 [details] 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
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).
Created attachment 139047 [details] The bad gif which causes the crash (in case the site corrects the problem) Attached the gif from the site so it would still be on file should the site correct the problem.
Bad gifs would be imagelib.
Possibly a duplicate of bug 229652.
14 years ago
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 ***