Closed Bug 521187 Opened 16 years ago Closed 14 years ago

crash [@ row_callback]

Categories

(Core :: Graphics: ImageLib, defect)

Product:
Core
Component:
Graphics: ImageLib
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: sspitzer, Unassigned)

Details

(Keywords: crash, Whiteboard: [sg:watch])

Crash Data

crash @ row_callback in the past three weeks there were 240 of these, see http://crash-stats.mozilla.com/report/list?query_search=signature&query_type=exact&query=row_callback&date=&range_value=3&range_unit=weeks&do_query=1&signature=row_callback 239 were on windows, one on mac: note it seems to be on 3.0.14 and 3.5.3. from firefox 3.0.14, http://crash-stats.mozilla.com/report/index/1fee5d2b-f819-4628-b290-520322091007 0 xul.dll row_callback mozilla/modules/libpr0n/decoders/png/nsPNGDecoder.cpp:782 1 xul.dll MOZ_PNG_push_proc_row mozilla/modules/libimg/png/pngpread.c:1010 2 xul.dll MOZ_PNG_proc_IDAT_data mozilla/modules/libimg/png/pngpread.c:984 3 xul.dll MOZ_PNG_push_read_IDAT mozilla/modules/libimg/png/pngpread.c:915 from firefox 3.5.3, http://crash-stats.mozilla.com/report/index/fcb2cf5d-1bbf-4ed1-9c3c-045ef2091007 0 xul.dll row_callback modules/libpr0n/decoders/png/nsPNGDecoder.cpp:722 1 xul.dll MOZ_PNG_push_proc_row modules/libimg/png/pngpread.c:1010 2 xul.dll MOZ_PNG_proc_IDAT_data modules/libimg/png/pngpread.c:984 3 xul.dll MOZ_PNG_push_read_IDAT modules/libimg/png/pngpread.c:915 the mac one has the best stack, see http://crash-stats.mozilla.com/report/index/d4b67ee7-3501-4673-800f-8f6952090920 0 XUL row_callback modules/libpr0n/decoders/png/nsPNGDecoder.cpp:784 1 XUL MOZ_PNG_push_proc_row modules/libimg/png/pngpread.c:1167 2 XUL MOZ_PNG_proc_IDAT_data modules/libimg/png/pngpread.c:984 3 XUL MOZ_PNG_push_read_IDAT modules/libimg/png/pngpread.c:915 4 XUL MOZ_PNG_process_data modules/libimg/png/pngpread.c:35 5 XUL ReadDataOut modules/libpr0n/decoders/png/nsPNGDecoder.cpp:351 6 XUL nsInputStreamTee::WriteSegmentFun xpcom/io/nsInputStreamTee.cpp:102 7 XUL nsPipeInputStream::ReadSegments xpcom/io/nsPipe3.cpp:799 8 XUL nsPNGDecoder::WriteFrom modules/libpr0n/decoders/png/nsPNGDecoder.cpp:370 9 XUL imgRequest::OnDataAvailable modules/libpr0n/src/imgRequest.cpp:993 10 XUL nsStreamListenerTee::OnDataAvailable netwerk/base/src/nsStreamListenerTee.cpp:97 11 XUL nsHttpChannel::OnDataAvailable netwerk/protocol/http/src/nsHttpChannel.cpp:5063 12 XUL nsInputStreamPump::OnStateTransfer netwerk/base/src/nsInputStreamPump.cpp:508 13 XUL nsInputStreamPump::OnInputStreamReady netwerk/base/src/nsInputStreamPump.cpp:398 14 XUL nsInputStreamReadyEvent::Run xpcom/io/nsStreamUtils.cpp:111 15 XUL nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:510 16 XUL NS_ProcessNextEvent_P nsThreadUtils.cpp:227 17 XUL nsThread::Shutdown xpcom/threads/nsThread.cpp:465 18 XUL XUL@0xb1df90 19 XUL nsProxyObjectCallInfo::Run xpcom/proxy/src/nsProxyEvent.cpp:181 20 XUL nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:510 21 XUL NS_ProcessPendingEvents_P nsThreadUtils.cpp:180 22 XUL nsBaseAppShell::NativeEventCallback widget/src/xpwidgets/nsBaseAppShell.cpp:121 23 XUL nsAppShell::ProcessGeckoEvents widget/src/cocoa/nsAppShell.mm:405 24 CoreFoundation CFRunLoopRunSpecific 25 HIToolbox RunCurrentEventLoopInMode 26 HIToolbox ReceiveNextEventCommon 27 HIToolbox BlockUntilNextEventMatchingListInMode 28 AppKit _DPSNextEvent 29 AppKit -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] 30 AppKit -[NSApplication run] 31 XUL nsAppShell::Run widget/src/cocoa/nsAppShell.mm:720 32 XUL nsAppStartup::Run toolkit/components/startup/src/nsAppStartup.cpp:193 33 XUL XRE_main toolkit/xre/nsAppRunner.cpp:3321 34 firefox-bin main browser/app/nsBrowserApp.cpp:156 35 firefox-bin firefox-bin@0x18b8
My apologies in advance if this is not a security issue. I did a bugzilla query, and found possibly related bug #414854
joedrew! Wanna take a look and see if anything obvious stands out with this crash?
The Mac crash and the first crash are the same issue, but the middle crash (at line 722) is entirely different. It'd be really handy to get some URLs for these crashes.
joed, unfortunately I don't have any URLs. Is that information in the crash reporter database?
Lars can pull out the information for us and attach it as a private attachment (which you can see, but won't be public when we open this bug, since the URLs might have privacy implications).
ss: I assume that you have access to the mount point for the daily url dump. You can get the url by grep'ng for the uuid in the file for the appropriate date.
Joe: Are these URLs helpful at all? Tomcat/Bob: Can we get these run through your automation?
Not terribly useful, no. :( Although I didn't check every one, I couldn't reproduce any crashes - and a lot of the crashes are from unuseful pages, like ones that redirect if you don't have their session cookie, or ones like http://facebook.com. One thing I'm starting to suspect is malformed PNG images as used in ads; even if they just cause memory corruption, then a crash later. A PNG fuzzer (with results run though valgrind, hope of hopes!) would go a long way.
But yes, if someone could run the automated "Does this page crash on load" test on the list of crashing URLs, that'd at least be an exhaustive way of proving whether any of those URLs are helpful.
(In reply to comment #9) > A PNG fuzzer (with results run though valgrind, hope of hopes!) would go a > long way. Jesse: Know anyone who has one of those or is working on such a fuzzer?
David Keeler wrote a PNG fuzzer (in fuzzing/mediafuzz).
Tomcat is already automatically scanning urls from the crashdata dumps, so I expect he is hitting these urls/signatures already. The main problem we have is the urls being reported to us are not reliable. Until bug 411930 is fixed we are limited as to how useful the crash scans or the crash urls are.
Severity: normal → critical
Keywords: crash
Summary: crash @ row_callback → crash [@ row_callback]
Group: core-security
Whiteboard: [sg:watch]
Whiteboard: [sg:watch] → [sg:critical?]
Whiteboard: [sg:critical?] → [sg:watch]
A few of the stacks fall under nsJARChannel::OnDataAvailable -- maybe we can find an add-on with a PNG that triggers this. bp-31d6bf75-6f20-4846-b97f-9ae512100303 AutoComplete Pro support@predictad.com 1.11 LavaFox V1 info@djzig.com 1.1.0 LavaFox V1-Blue djziggy@gmail.com 1.1.0 bp-228a9491-70e0-4742-87ec-a650b2100306 {CAFEEFAC-0016-0000-0015-ABCDEFFEDCBA} 6.0.15 {CAFEEFAC-0016-0000-0017-ABCDEFFEDCBA} 6.0.17 jqs@sun.com 1.0 bp-954333aa-1d19-482e-a388-708272100310 jqs@sun.com 1.0 moveplayer@movenetworks.com 7 bp-33027236-f472-484f-8dee-9550d2100310 Greasemonkey {e4a8a97b-f2ed-450b-b12d-ee082ba24781} 0.8.20100211.5 Microsoft .NET Framework Assistant {20a82645-c095-46ed-80e3-08825760534b} 1.1 bp-e44cfe4a-3058-454f-8f30-62be02100307 -- no extensions except default theme -- (yet still crashes in nsJARChannel? several of these) This is only a minority of the row_callback crashes, but it's maybe more of a starting point. No common addons except the default theme.
I have hit a crash in row_callback locally and got it in a debugger. Stack: > xul.dll!mozilla::imagelib::nsPNGDecoder::row_callback(png_struct_def * png_ptr, unsigned char * new_row, unsigned int row_num, int pass) Line 758 + 0x113 bytes C++ xul.dll!MOZ_PNG_push_have_row(png_struct_def * png_ptr, unsigned char * row) Line 1914 + 0x28 bytes C xul.dll!MOZ_PNG_push_proc_row(png_struct_def * png_ptr) Line 1317 + 0x16 bytes C xul.dll!MOZ_PNG_proc_IDAT_data(png_struct_def * png_ptr, unsigned char * buffer, unsigned int buffer_length) Line 1101 + 0x9 bytes C xul.dll!MOZ_PNG_push_read_IDAT(png_struct_def * png_ptr) Line 995 + 0x17 bytes C xul.dll!MOZ_PNG_proc_some_data(png_struct_def * png_ptr, png_info_struct * info_ptr) Line 70 + 0x9 bytes C xul.dll!MOZ_PNG_process_data(png_struct_def * png_ptr, png_info_struct * info_ptr, unsigned char * buffer, unsigned int buffer_size) Line 41 + 0xd bytes C xul.dll!mozilla::imagelib::nsPNGDecoder::WriteInternal(const char * aBuffer, unsigned int aCount) Line 354 + 0x1b bytes C++ xul.dll!mozilla::imagelib::Decoder::Write(const char * aBuffer, unsigned int aCount) Line 104 C++ xul.dll!mozilla::imagelib::RasterImage::WriteToDecoder(const char * aBuffer, unsigned int aCount) Line 2258 C++ xul.dll!mozilla::imagelib::RasterImage::AddSourceData(const char * aBuffer, unsigned int aCount) Line 1229 + 0x10 bytes C++ xul.dll!mozilla::imagelib::RasterImage::WriteToRasterImage(nsIInputStream * __formal, void * aClosure, const char * aFromRawSegment, nsIInputStream * __formal, unsigned int aCount, unsigned int * aWriteCount) Line 2754 C++ xul.dll!nsPipeInputStream::ReadSegments(unsigned int (nsIInputStream *, void *, const char *, unsigned int, unsigned int, unsigned int *)* writer, void * closure, unsigned int count, unsigned int * readCount) Line 799 + 0x1d bytes C++ xul.dll!imgRequest::OnDataAvailable(nsIRequest * aRequest, nsISupports * ctxt, nsIInputStream * inStr, unsigned int sourceOffset, unsigned int count) Line 1152 + 0x2a bytes C++ xul.dll!ProxyListener::OnDataAvailable(nsIRequest * aRequest, nsISupports * ctxt, nsIInputStream * inStr, unsigned int sourceOffset, unsigned int count) Line 2020 C++ xul.dll!nsJARChannel::OnDataAvailable(nsIRequest * req, nsISupports * ctx, nsIInputStream * stream, unsigned int offset, unsigned int count) Line 937 + 0x3b bytes C++ xul.dll!nsInputStreamPump::OnStateTransfer() Line 510 + 0x40 bytes C++ xul.dll!nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream * stream) Line 400 + 0xb bytes C++ xul.dll!nsInputStreamReadyEvent::Run() Line 113 C++ xul.dll!nsThread::ProcessNextEvent(int mayWait, int * result) Line 633 + 0x19 bytes C++ xul.dll!NS_ProcessNextEvent_P(nsIThread * thread, int mayWait) Line 250 + 0x16 bytes C++ xul.dll!mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate * aDelegate) Line 110 + 0xe bytes C++ xul.dll!MessageLoop::RunInternal() Line 220 C++ xul.dll!MessageLoop::RunHandler() Line 203 C++ xul.dll!MessageLoop::Run() Line 177 C++ cptr32 is null. decoder->mImageData is null. row_num is 0. x is 15. Image is ARGB32. Image size is 15x15. Image URL is "chrome://global/skin/icons/resizer.png". decoder->mImage->mError is false. decoder->mDataError is false. In OnDataAvailable, offset is 0 and count is 197. decoder->mFrames.Length() is 1. The imgFrame's mImageSurface looks OK. In particular its Data() is non-null. The imgFrame's mIsLocked is true. mPNG->mode is 261, mPNG->flags is 576, mPNG->transformations is 24576. decoder->mFrameRect is 0,0,15,15. This is a debug build, so obviously no NS_ABORT_IF_FALSE conditions were hit. There don't seem to be any relevant assertions or warnings on the console. It looks like decoder->CreateFrame was called --- mFrameRect is set and mFrameHasNoAlpha is true --- but then how did decoder->mImageData end up null?
The previous comment may have been a corrupt build, ignore.
Crash Signature: [@ row_callback]
No record of recent crashes.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.