Last Comment Bug 627015 - ABORT: What is the next frame supposed to be?: 'haveFullNextFrame || (mDecoder && mFrames.Length() > mDecoder->GetCompleteFrameCount())'
: ABORT: What is the next frame supposed to be?: 'haveFullNextFrame || (mDecode...
Status: VERIFIED FIXED
[sg:dos (self-inflicted)][inbound]
: assertion
Product: Core
Classification: Components
Component: ImageLib (show other bugs)
: Trunk
: x86 All
: -- blocker (vote)
: mozilla8
Assigned To: Joe Drew (not getting mail)
:
Mentors:
http://www.7m.cn
: 671977 (view as bug list)
Depends on:
Blocks: 532972
  Show dependency treegraph
 
Reported: 2011-01-19 06:56 PST by Carsten Book [:Tomcat]
Modified: 2013-12-27 14:29 PST (History)
16 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-
-


Attachments
Sometimes, images pause mid-frame when downloading. We handle this just fine, but unfortunately we assert that it's not the case. Since this assertion is just bogus, delete it. (1.91 KB, patch)
2011-07-19 16:10 PDT, Joe Drew (not getting mail)
jmuizelaar: review+
Details | Diff | Splinter Review
Add a crashtest for an image that takes a very long time to download the next frame, giving our animation timer a chance to fire. (3.22 KB, patch)
2011-07-19 16:10 PDT, Joe Drew (not getting mail)
jmuizelaar: review+
Details | Diff | Splinter Review

Description Carsten Book [:Tomcat] 2011-01-19 06:56:51 PST
Crashed during Topsite run on http://www.7m.cn: EXIT STATUS: CRASHED signal 10 SIGBUS (162.840153 seconds) with Mac Trunk Debug Build

###!!! ABORT: What is the next frame supposed to be?: 'haveFullNextFrame || (mDecoder && mFrames.Length() > mDecoder->GetCompleteFrameCount())', file /work/mozilla/builds/2.0.0/mozilla/modules/libpr0n/src/RasterImage.cpp, line 1405

http://www.7m.cn: EXIT STATUS: CRASHED signal 10 SIGBUS (162.840153 seconds)

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   libmozalloc.dylib             	0x04f24e34 TouchBadMemory() + 17 (mozalloc_abort.cpp:64)
1   libmozalloc.dylib             	0x04f24e8f mozalloc_abort(char const*) + 69 (mozalloc_abort.cpp:88)
2   XUL                           	0x000222d4 GetAssertBehavior() + 0 (nsDebugImpl.cpp:192)
3   XUL                           	0x000227cf NS_DebugBreak_P + 702 (nsDebugImpl.cpp:338)
4   XUL                           	0x0028e7fb mozilla::imagelib::RasterImage::Notify(nsITimer*) + 867 (RasterImage.cpp:1409)
5   XUL                           	0x0180c5b4 nsTimerImpl::Fire() + 1284 (nsTimerImpl.cpp:429)
6   XUL                           	0x0180c80b nsTimerEvent::Run() + 217 (nsTimerImpl.cpp:519)
7   XUL                           	0x01804bff nsThread::ProcessNextEvent(int, int*) + 907 (nsThread.cpp:633)
8   XUL                           	0x01788c93 NS_ProcessPendingEvents_P(nsIThread*, unsigned int) + 146 (nsThreadUtils.cpp:200)
9   XUL                           	0x014606b1 nsBaseAppShell::NativeEventCallback() + 181 (nsBaseAppShell.cpp:133)
10  XUL                           	0x0140e625 nsAppShell::ProcessGeckoEvents(void*) + 497 (nsAppShell.mm:400)
11  com.apple.CoreFoundation      	0x960c64cb __CFRunLoopDoSources0 + 1563
12  com.apple.CoreFoundation      	0x960c3f8f __CFRunLoopRun + 1071
13  com.apple.CoreFoundation      	0x960c3464 CFRunLoopRunSpecific + 452
14  com.apple.CoreFoundation      	0x960c3291 CFRunLoopRunInMode + 97
15  com.apple.HIToolbox           	0x953ac004 RunCurrentEventLoopInMode + 392
16  com.apple.HIToolbox           	0x953abdbb ReceiveNextEventCommon + 354
17  com.apple.HIToolbox           	0x953abc40 BlockUntilNextEventMatchingListInMode + 81
18  com.apple.AppKit              	0x92df578d _DPSNextEvent + 847
19  com.apple.AppKit              	0x92df4fce -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 156
20  com.apple.AppKit              	0x92db7247 -[NSApplication run] + 821
21  XUL                           	0x0140d323 nsAppShell::Run() + 291 (nsAppShell.mm:746)
22  XUL                           	0x0114cb16 nsAppStartup::Run() + 148 (nsAppStartup.cpp:191)
23  XUL                           	0x0003fc29 XRE_main + 11868 (nsAppRunner.cpp:3695)
24  org.mozilla.firefoxdebug      	0x000025f1 main + 714 (nsBrowserApp.cpp:158)
25  org.mozilla.firefoxdebug      	0x00002272 start + 54
Comment 1 Bob Clary [:bc:] 2011-01-19 07:20:54 PST
I've seen this on 7 urls from 2010-12-20T23:25:25 - 2011-01-18T08:16:49 on Mac OS X 10.5 intel only.
Comment 2 chris hofmann 2011-01-24 12:44:13 PST
is this the same as socorro crash 
[@ mozilla::imagelib::RasterImage::DrawFrameTo(imgFrame*, imgFrame*, nsIntRect&) ]

http://crash-stats.mozilla.com/report/list?signature=mozilla%3A%3Aimagelib%3A%3ARasterImage%3A%3ADrawFrameTo%28imgFrame*%2C%20imgFrame*%2C%20nsIntRect%26%29
Comment 3 Bob Clary [:bc:] 2011-03-17 05:01:36 PDT
FYI: I see this daily in the crash test automation. The domains I've reproduced
it on so far are:

5giay.vn, aglaonemaonline.wordpress.com, ak.178.com, ale-aukcje.pl, animeq-ja.blogspot.com, azz-overload.net, b3ta.com, bbs.3dmgame.com, bbs.goapk.com, bbs.temox.com, bbs.voc.com.cn, bbs.weiphone.com, benyouhui.it168.com, board.postjung.com, book.zongheng.com, bsnl.co.in, cf.766.com, cinemaxx.ru, clubs.ya.ru, data.movie.xunlei.com, dek-d.com, dematom.com, desciclopedia.org, dethi.zinaki.com, dnbforum.com, extra2.bsgi.org.br, fanfiction.nyah.com.br, filiza.ru, filmehd.net, filmix.net, forum.brest.by, forum.stop55.com, foto-mult.ru, funnyjunk.com, game.ali213.net, gaydar.co.uk, getdrivesafe.com, home.blogtruyen.com, hurtom.com, hvg.hu, item.taobao.com, jeddah-lx.com, jyukujyo1.blog86.fc2.com, kapook.com, keep4u.ru, kenhsinhvien.net, klikajadeh.com, manga24h.com, masteroff.org, me.zing.vn, nnm.ru, onua.com.ua, p0rno-tv.com, pes-land.ru, picpost.postjung.com, porevo.info, pornonights.ru, porntuba.ru, proc.com.ua, product.it168.com, quangcaogiare.vn, rds-zone.ro, realmentecaseiras.blogspot.com, reddodo.com, rutracker.org, rutracker.ru, sacanagembr.com, sancharnet.in, sfw.org.ua, share.earthlinktele.com, skyclipart.ru, softvnn.com, sport.ro, spotato.net, stafaband.info, stalker74.do.am, supernatural.chudoforum.ru, tagboards.miarroba.es, tieba.baidu.com, top.l2jbrasil.com, trenietreni.it, tt.mop.com, tvdedegraca-i.blogspot.com, verdadescristianas.blogcindario.com, vnsharing.net, wadize2ab.com, www.56.com, www.91baby.com, www.alshmalgate.net, www.aridesa.com.br, www.b-g4ever.com, www.bdh16.gov.tr, www.bolero.ru, www.bommeltje.nl, www.bsnl.co.in, www.celebjihad.com, www.clubthai-it.com, www.corluzz.co.cc, www.cortag.com.br, www.cuplari.ro, www.darkzone.in.th, www.dek-d.com, www.dilforum.com, www.divertiviaggi.it, www.drb-al56r.com, www.driva-eget.se, www.egy4n.com, www.ehentai.ru, www.el7akeem.com, www.erotycznyblog.pl, www.fatimanews.com.br, www.filmai.in, www.franchise108.com, www.gameqq.net, www.gaydar.nl, www.gillmarine.com, www.goosiam.com, www.hacken.cc, www.hazirfilm.com, www.hinata.xpg.com.br, www.i11i.net, www.ibnmsr.com, www.indowebster.com, www.indowebster.web.id, www.j-doramanga.com, www.jambotube.com, www.jobmonitor.hu, www.jorgeemateus.com.br, www.k-gameonline.com, www.klikajadeh.com, www.knowsky.com, www.lastfm.pl, www.libertatea.ro, www.livefilmeporno.com, www.macx.cn, www.maisfutebol.iol.pt, www.manodrabuziai.lt, www.mapion.co.jp, www.masterporn.ru, www.megafilex.com, www.myanmarhiphopchannel.com, www.okbole.com, www.phueanthae.in.th, www.pixiv.net, www.playstation-android.sk, www.playxp.com, www.pokemonmythology.110mb.com, www.pokexperto.net, www.pornbb.org, www.pornotesao.com, www.portalfilmes.org, www.proground.org.ru, www.raamas.com, www.rabota.ru, www.radialistas.net, www.rashedalmajid.com, www.rustorrents.net, www.saberdetudo.com.br, www.sakh.com, www.samsunsporluyuz.net, www.seed18up.net, www.series.el3lam.com, www.sexyboard.org, www.shum2money.ru, www.sisaketfc.com, www.smaxi.net, www.smayli.ru, www.spicycute.com, www.spoki.lv, www.sport.ro, www.stepashka.com, www.telaerotica.com, www.thailandsusu.com, www.tportal.hr, www.tran33m.com, www.tuifly.com, www.tvguide.co.uk, www.uol.com.br, www.vatgia.com, www.xxx4u.ru, www.yugionline.com.br, www.zavarka.ru, www.zimabdk.com, www3.familyoldphotos.com, xahoithongtin.com.vn, xemtiep.com, xuk.ru, yourserv.ru, zerx.ru, ziapps.com, znamenitosti-na-foto.ru, zona-zona-internet.blogspot.com

Note that I only tested the urls on these sites because our users are crashing
there.
Comment 4 Bob Clary [:bc:] 2011-03-30 11:19:09 PDT
This continues to be a common Abort during crash automation testing. It can cause issues for automated testing by potentially hiding other crashes.

If it isn't important enough to fix, then perhaps it should be a non-fatal ASSERTION rather than an Abort?
Comment 5 Daniel Holbert [:dholbert] 2011-04-22 15:37:09 PDT
FWIW, we just hit this abort during a tbox reftest run - filed Bug 652238.
Comment 6 Carsten Book [:Tomcat] 2011-05-20 07:08:37 PDT
also hitting this again on the topsite tests for firefox 5 beta 

###!!! ABORT: What is the next frame supposed to be?: 'haveFullNextFrame || (mDecoder && mFrames.Length() > mDecoder->GetCompleteFrameCount())', file /work/mozilla/builds/firefox5/mozilla-beta/modules/libpr0n/src/RasterImage.cpp, line 1466

http://www.ujap.edu.ve: EXIT STATUS: CRASHED signal 10 SIGBUS (311.669375 seconds)

joe is this something to fix for firefox 5?
Comment 7 Carsten Book [:Tomcat] 2011-05-24 00:31:51 PDT
to add something for the domains here its also on elite-view.com
Comment 8 Daniel Veditz [:dveditz] 2011-05-24 12:33:15 PDT
This is blocking crash test automation. It appears to be a widespread problem and needs to be handled differently than a runtime abort. If it's a problem in our code we need another way to fix it. If it's simply reporting an error in the image then it definitely shouldn't be an abort -- the web is full of crap.
Comment 9 Daniel Veditz [:dveditz] 2011-05-24 12:34:45 PDT
may not rate landing on the beta branch unless it's a topcrash, but Fx6 for sure.
Comment 10 Daniel Veditz [:dveditz] 2011-05-24 12:36:12 PDT
--> joe per bug 609499 comment 7
Comment 11 Bob Clary [:bc:] 2011-06-16 08:03:25 PDT
This is still a common issue in crash testing on 2.0.0, Beta, Aurora, and Nightly on Windows, Mac, Linux.

Does this really qualify to be a fatal assertion? Can it be demoted to just an NS_ASSERTION ?
Comment 12 Joe Drew (not getting mail) 2011-07-15 17:49:34 PDT
*** Bug 671977 has been marked as a duplicate of this bug. ***
Comment 13 Daniel Holbert [:dholbert] 2011-07-15 19:16:45 PDT
FWIW, the URL where Scott periodically hit this when filing duplicate bug 671977 was:
http://chat.vitebsk.ws/smile.php?name=kolobki2&jsclose=1&PHPSESSID=712fb5f997934bf52dbaf00e73fe81ea
(warning: lots of animated gifs there ^, tends to slow down browser)
Comment 14 Asa Dotzler [:asa] 2011-07-17 23:19:29 PDT
We're getting deep into 6 Beta and I don't think we'd take anything that wasn't really safe at this point. Is that likely in the next week or so?
Comment 15 Joe Drew (not getting mail) 2011-07-18 15:49:29 PDT
This is just a fatal assertion in debug builds. I'm not clear on why it was marked tracking for Fx6; it probably shouldn't be.
Comment 16 Carsten Book [:Tomcat] 2011-07-19 00:31:26 PDT
(In reply to comment #15)
> This is just a fatal assertion in debug builds. I'm not clear on why it was
> marked tracking for Fx6; it probably shouldn't be.

i think it was marked because of the reasons in comment #8 - since other crashes can hide etc
Comment 17 Bob Clary [:bc:] 2011-07-19 04:26:29 PDT
For example, last night I hit this abort locally while investigating a crash with a stack like nsXULTemplateBuilder::Uninit nsXULTemplateBuilder::~nsXULTemplateBuilder nsXULContentBuilder::~nsXULContentBuilder nsXULTemplateBuilder::Release nsXPCOMCycleCollectionParticipant::Unroot 

As you can see in comment 3, this abort is common place and interferes with crash testing.
Comment 18 Scott Johnson (:jwir3) 2011-07-19 14:28:55 PDT
Is there a reason we can't just skip the NS_ABORT_IF_FALSE? It seems like later on in the function the check is performed to determine if the next frame is there, and it waits if it's not... so it doesn't seem like there is any reason why the ABORT can't be changed to WARN.
Comment 19 Joe Drew (not getting mail) 2011-07-19 16:10:20 PDT
Created attachment 546934 [details] [diff] [review]
Sometimes, images pause mid-frame when downloading. We handle this just fine, but unfortunately we assert that it's not the case. Since this assertion is just bogus, delete it.
Comment 20 Joe Drew (not getting mail) 2011-07-19 16:10:35 PDT
Created attachment 546935 [details] [diff] [review]
Add a crashtest for an image that takes a very long time to download the next frame, giving our animation timer a chance to fire.
Comment 21 Jeff Muizelaar [:jrmuizel] 2011-07-21 07:17:30 PDT
Comment on attachment 546935 [details] [diff] [review]
Add a crashtest for an image that takes a very long time to download the next frame, giving our animation timer a chance to fire.

Why do we use @mozilla.org/timer instead of setTimeout?
Comment 22 Joe Drew (not getting mail) 2011-07-21 09:26:27 PDT
setTimeout is an attribute on the window object, and we don't have a window object.
Comment 23 Jeff Muizelaar [:jrmuizel] 2011-07-22 08:46:01 PDT
Comment on attachment 546935 [details] [diff] [review]
Add a crashtest for an image that takes a very long time to download the next frame, giving our animation timer a chance to fire.

Add a comment about where 5 seconds come from. i.e. what time does it need to be larger than.
Comment 24 Bob Clary [:bc:] 2011-08-01 05:51:40 PDT
Joe, this is still significantly affecting crash testing. Can we land this soon?
Comment 25 Johnny Stenback (:jst, jst@mozilla.com) 2011-08-01 14:55:04 PDT
Seems this is ready to land, but we won't get this for 6 any more, nor do I think it's critical enough to rush in. tracking6-.
Comment 27 Joe Drew (not getting mail) 2011-08-03 13:44:09 PDT
Ms2ger found an important bug in my crashtest (not holding on to a reference to the timer), so I quickly pushed a fix:

http://hg.mozilla.org/integration/mozilla-inbound/rev/a232c0a78713
Comment 29 Bob Clary [:bc:] 2011-08-11 10:59:05 PDT
verified. not seen in automation since 8/5.

Note You need to log in before you can comment on or make changes to this bug.