Closed Bug 354997 Opened 19 years ago Closed 19 years ago

Startup crash [@ MOZ_PNG_do_read_int]

Categories

(Core :: Graphics: ImageLib, defect)

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

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: philor, Assigned: glennrp+bmo)

References

Details

Attachments

(4 files, 1 obsolete file)

crash log
24.73 KB, text/plain
Details
Avoid Mac Intel crash in libpng-1.2.12 pnggccrd.c (v2) (checked in)
757 bytes, patch
pavlov
: review+
pavlov
: superreview+
Details | Diff | Splinter Review
stack to crash from gdb
7.21 KB, text/plain
Details
crash report
33.02 KB, text/plain
Details
Since the afternoon of 29 September, my trunk builds on (Intel) Mac all crash at startup, with the same stack from Apple's Crash Reporter: Thread 0 Crashed: 0 org.mozilla.firefox 0x00729be8 MOZ_PNG_do_read_int + 1326 1 org.mozilla.firefox 0x00729cce MOZ_PNG_read_filt_row + 217 2 org.mozilla.firefox 0x0056b7ca MOZ_PNG_push_proc_row + 173 3 org.mozilla.firefox 0x0056b6d4 MOZ_PNG_proc_IDAT_data + 188 4 org.mozilla.firefox 0x0056b5b1 MOZ_PNG_push_read_IDAT + 443 5 org.mozilla.firefox 0x0056abac MOZ_PNG_proc_some_data + 95 6 org.mozilla.firefox 0x0056ab3d MOZ_PNG_process_data + 57 7 org.mozilla.firefox 0x0027684a nsICODecoder::ReadSegCb(nsIInputStream*, void*, char const*, unsigned, unsigned, unsigned*) + 266 8 libxpcom_core.dylib 0x00e2ca04 nsPipe::OnPipeException(unsigned, int) + 884 9 org.mozilla.firefox 0x00276893 nsICODecoder::ReadSegCb(nsIInputStream*, void*, char const*, unsigned, unsigned, unsigned*) + 339 10 org.mozilla.firefox 0x0057325f imgRequest::Priority() const + 1165 11 org.mozilla.firefox 0x0027d00c imgLoader::imgLoader[in-charge]() + 268 12 org.mozilla.firefox 0x0038f3bf nsJARInputStream::ContinueInflate(char*, unsigned, unsigned*) + 1497 13 org.mozilla.firefox 0x000a0a89 nsInputStreamPump::OnStateTransfer() + 271 14 org.mozilla.firefox 0x000a0b9a nsInputStreamPump::OnStateTransfer() + 544 15 libxpcom_core.dylib 0x00e70615 nsStreamCopierIB::DoCopy(unsigned*, unsigned*) + 137 16 libxpcom_core.dylib 0x00e44e8c nsThread_GetInterfacesHelper(unsigned*, nsID***) + 390 17 libxpcom_core.dylib 0x00e0cabd NS_ProcessNextEvent_P(nsIThread*, int) + 53 18 libxpcom_core.dylib 0x00e455d2 nsThread::Init() + 1080 19 libxpcom_core.dylib 0x00e4fcc3 XPTC_InvokeByIndex + 81 20 libxpcom_core.dylib 0x00e491af nsProxyObjectCallInfo::PostCompleted() + 185 21 libxpcom_core.dylib 0x00e44e8c nsThread_GetInterfacesHelper(unsigned*, nsID***) + 390 22 libxpcom_core.dylib 0x00e0cabd NS_ProcessNextEvent_P(nsIThread*, int) + 53 23 org.mozilla.firefox 0x0057382f nsBaseAppShell::DoProcessNextNativeEvent(int) + 103 24 org.mozilla.firefox 0x0027edc5 nsAppShell::ProcessNextNativeEvent(int) + 525 25 org.mozilla.firefox 0x0027efef nsAppShell::ProcessNextNativeEvent(int) + 1079 26 com.apple.Foundation 0x9273eed3 __NSFireDelayedPerform + 403 27 com.apple.CoreFoundation 0x90823bc9 CFRunLoopRunSpecific + 3341 28 com.apple.CoreFoundation 0x90822eb5 CFRunLoopRunInMode + 61 29 com.apple.HIToolbox 0x92f02b90 RunCurrentEventLoopInMode + 285 30 com.apple.HIToolbox 0x92f021ce ReceiveNextEventCommon + 184 31 com.apple.HIToolbox 0x92f020ee BlockUntilNextEventMatchingListInMode + 81 32 com.apple.AppKit 0x933a3771 _DPSNextEvent + 576 33 com.apple.AppKit 0x933a335e -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 137 34 com.apple.AppKit 0x9339d0e3 -[NSApplication run] + 512 35 org.mozilla.firefox 0x0027eda7 nsAppShell::ProcessNextNativeEvent(int) + 495 36 org.mozilla.firefox 0x003110a7 nsAppStartup::AttemptingQuit(int) + 245 37 org.mozilla.firefox 0x00007828 XRE_main + 10818 38 org.mozilla.firefox 0x00003018 main + 32 39 org.mozilla.firefox 0x00002f9e start + 270 40 org.mozilla.firefox 0x00002eb9 start + 41 Backing out the checkin from bug 334110 makes the crash go away.
Attached file crash log —
Seeing it here too with a fresh profile (crash log attached). If I use my old profile, I can launch and even surf some pages successfully. However, attempting to enter the Mozillazine forums is one page that crashes Camino every time with the MOZ_PNG in the log.
Found one official build since the bug 334110 checkin, from xserve03's Firefox-Cairo build. That crashes slightly differently, showing the profile manager, with Thread 0 Crashed: 0 org.mozilla.firefox 0x0072f88e MOZ_PNG_crc_error + 6 1 org.mozilla.firefox 0x00566c80 MOZ_PNG_push_proc_row + 159 2 org.mozilla.firefox 0x005670c0 MOZ_PNG_proc_IDAT_data + 65 3 org.mozilla.firefox 0x005673cc MOZ_PNG_push_read_IDAT + 558 4 org.mozilla.firefox 0x005679de MOZ_PNG_process_data + 65 5 org.mozilla.firefox 0x002664d4 nsPNGDecoder::~nsPNGDecoder [in-charge deleting]() + 272 6 libxpcom_core.dylib 0x00e2b875 nsPipe::OnPipeException(unsigned, int) + 947 7 org.mozilla.firefox 0x0026652b nsPNGDecoder::~nsPNGDecoder [in-charge deleting]() + 359 8 org.mozilla.firefox 0x0056edac imgRequest::Priority() const + 852 9 org.mozilla.firefox 0x00393297 nsJARInputStream::ContinueInflate(char*, unsigned, unsigned*) + 1407 10 org.mozilla.firefox 0x0009fcf8 nsInputStreamPump::OnStateTransfer() + 308 11 org.mozilla.firefox 0x0009fe2f nsInputStreamPump::OnStateTransfer() + 619 12 libxpcom_core.dylib 0x00e6f9c7 nsStreamCopierIB::DoCopy(unsigned*, unsigned*) + 139 13 libxpcom_core.dylib 0x00e44039 nsThread_GetInterfacesHelper(unsigned*, nsID***) + 353 14 libxpcom_core.dylib 0x00e0c759 NS_ProcessNextEvent_P(nsIThread*, int) + 35 15 org.mozilla.firefox 0x0036f427 nsXULWindow::SetContentScrollbarVisibility(int) + 2519 16 org.mozilla.firefox 0x0022b56a nsWindowWatcher::OpenWindowJSInternal(nsIDOMWindow*, char const*, char const*, char const*, int, nsIArray*, int, nsIDOMWindow**) + 2594 17 org.mozilla.firefox 0x0022bc29 nsWindowWatcher::OpenWindowJSInternal(nsIDOMWindow*, char const*, char const*, char const*, int, nsIArray*, int, nsIDOMWindow**) + 4321 18 org.mozilla.firefox 0x000035d0 ScopedXPCOMStartup::RegisterProfileService(nsIToolkitProfileService*) + 758 19 org.mozilla.firefox 0x0000667e XRE_main + 9310 20 org.mozilla.firefox 0x00002578 main + 32 21 org.mozilla.firefox 0x000024fe start + 270 22 org.mozilla.firefox 0x00002419 start + 41 But, since it's a universal build, unlike my own, I can run it under Rosetta, where it's dog-slow and broken-appearing, but seems to run just fine without a hint of crashing.
As a workaround, adding #define PNG_NO_ASSEMBLER_CODE to libimg/png/mozpngconf.h or adding "-DPNG_NO_ASSEMBER_CODE" to the compiler flags should allow it to run on any platform.
Taking bug. Phil: Does your intel Mac set the "__MMX__" flag (four underscores) while compiling? Can you convert "MOZ_PNG_do_read_int + 1326" into a line number in the png_do_read_interlace() function in pnggccrd.c?
Assignee: nobody → glennrp
Status: NEW → ASSIGNED
(In reply to comment #4) > Does your intel Mac set the "__MMX__" flag (four underscores) while > compiling? Assuming the advice I got to throw an #if defined(__MMX__) printf... in somewhere was good, yes it does. > Can you convert "MOZ_PNG_do_read_int + 1326" into a line > number in the png_do_read_interlace() function in pnggccrd.c? Not without detailed step-by-step instructions, no. I don't come close to knowing what I'm doing, and the odd fact that a debug build doesn't crash isn't helping.
>debug build doesn't crash Smells like a compiler optimization bug.
Phil: Does it run properly if you use #define PNG_NO_MMX_CODE in mozpngconf.h or with the CFLAG -DPNG_NO_MMX_CODE
(In reply to comment #7) > Does it run properly if you use #define PNG_NO_MMX_CODE in mozpngconf.h Yes, works fine.
Good. Does it also work if you put #ifdef MACOS #define PNG_NO_MMX_CODE #endif in mozpngconf.h If so, that could be the patch for this bug.
Similar to bug # 355089, crash exhibits on both my Intel Macs on launch, with MOZ_PNG causing a bad instruction.
*** Bug 355089 has been marked as a duplicate of this bug. ***
Joel: please try the patch.
#ifdef MACOS doesn't work (haven't checked yet whether because it's not defined yet, or because it's not defined), but #ifdef XP_MACOSX works fine.
with my fresh, mac os x, debug trunk build from this morning (10/2/06), I'm crashing on startup and I think it is related to this bug, but the stack is a little different. I'll attach the stack and crash report, and then try the patch out for glenn.
> please try the patch. after applying the patch and rebuilding, I no longer crash on startup.
Comment on attachment 240944 [details] [diff] [review] Avoid Mac Intel crash in libpng-1.2.12 pnggccrd.c (v2) (checked in) stuart, could you review this patch?
Attachment #240944 - Flags: review?(pavlov)
Comment on attachment 240944 [details] [diff] [review] Avoid Mac Intel crash in libpng-1.2.12 pnggccrd.c (v2) (checked in) We should really add some compiler version checks in here -- it works with whatever the latest stuff I have on my machine is. Just the compiler we're building nightlies with seems to have a problem...
That would be OK. Does anyone have a Mac that compiles pnggccrd.c correctly and sets the "__MMX__" compiler flag? Would those of you who experienced crashes please report your compiler version?
>>debug build doesn't crash >Smells like a compiler optimization bug. note, it was my debug build that was crashing. > We should really add some compiler version checks in here stuart? what check should we do? is this something we could add to mozilla/configure.in? fwiw, here is the result of "gcc -v" on my machine: Using built-in specs. Target: i686-apple-darwin8 Configured with: /private/var/tmp/gcc/gcc-5250.obj~20/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --build=powerpc-apple-darwin8 --with-arch=pentium-m --with-tune=prescott --program-prefix= --host=i686-apple-darwin8 --target=i686-apple-darwin8 Thread model: posix gcc version 4.0.1 (Apple Computer, Inc. build 5250)
I'm having trouble applying the patch, probably not cd-ing into the proper directory? (I'm not real good at this either). Anyway, it looks like this is under control. Or, email me off list with instructions to keep this bug uncluttered.
gcc -v Using built-in specs. Target: i686-apple-darwin8 Configured with: /private/var/tmp/gcc/gcc-5363.obj~28/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=powerpc-apple-darwin8 --with-arch=nocona --with-tune=generic --program-prefix= --host=i686-apple-darwin8 --target=i686-apple-darwin8 Thread model: posix gcc version 4.0.1 (Apple Computer, Inc. build 5363)
> Does anyone have a Mac that compiles pnggccrd.c correctly and sets the "__MMX__" compiler flag? my mac build (which is crashing, so it must not be compiling pnggccrd.c correctly), does set __MMX__.
(In reply to comment #24) > I'm having trouble applying the patch cd to your top-level directory (above "mozilla") patch -i *diff -p0
(In reply to comment #23) > > stuart? what check should we do? is this something we could add to > mozilla/configure.in? It would be best to put it in libimg/png/mozpngconf.h That way it will be simple to migrate back to libpng itself (we'd just lift whatever we come up with here and put it in libpng/pngconf.h)
(In reply to comment #27) > (In reply to comment #24) > > I'm having trouble applying the patch > > cd to your top-level directory (above "mozilla") > patch -i *diff -p0 > Thanks Glenn. Looks good, I'm using the resulting build right now.
(In reply to comment #24) > It would be best to put it in libimg/png/mozpngconf.h > That way it will be simple to migrate back to libpng itself (we'd just lift > whatever we come up with here and put it in libpng/pngconf.h) Yikes, maybe not. mozpngconf.h is under MPL and pngconf.h isn't. So we should put it in pngconf.h instead, even though policy is not to mess with the third-party library sources if possible. Just for the record, I tried the patch in pngconf.h before posting it here, so the path is actually libpng -> mozilla which should not raise any licensing issues.
I don't care which file we put it in -- which one is better? I'd like to get this fix in ASAP. Then we can figure out what compiler version/release/flags are causing the problem and come up with a better fix.
It makes more sense to put it in mozpngconf.h along with all the other mozilla customization of libpng. Meanwhile I've put it in libpng-1.2.13beta1, in pngconf.h where it will eventually reside. Sorry about being grumpy about the licensing. I had just been reading about the debian/firefox squabble and wanted to avoid falling into a trap like that. Incidentally, the libpng developers were unaware of the Mac-Intel problem. Anyone having a Mac-intel and interested in debugging this, please join png-mng-implement by visiting https://lists.sourceforge.net/lists/listinfo/png-mng-implement
Comment on attachment 240944 [details] [diff] [review] Avoid Mac Intel crash in libpng-1.2.12 pnggccrd.c (v2) (checked in) lets land this
Attachment #240944 - Flags: superreview+
Attachment #240944 - Flags: review?(pavlov)
Attachment #240944 - Flags: review+
checked in.
Just pulled a fresh source... looking good!
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
some people are still crashing on startup and the mac firefox tinderbox is still crashing running its tests. I'll try to get a new stacktrace. crowder can you post a new stacktrace?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Despite having blamed the tinderbox on this originally, the bug 334110 checkin was in its last build that actually successfully ran tests - the first failed one only picked up some js/ (plus, it's PPC and I haven't heard of anything but Intel problems with PNG (though, without nightlies, how would I?)). Filed bug 355192 on the tbox.
I am no longer experiencing this crash. Mark fixed?
yeah i think this is resolved.. everyone i've talked to says it is fixed now
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → FIXED
I would appreciate someone with an Intel/Mac system applying the "rc2" patch from bug #386585 (upgrade to libpng-1.2.19) and making sure this problem doesn't regress. Libpng-1.2.19 will be out in a few days and I'd rather find that out before making the release.
Attachment #240944 - Attachment description: Avoid Mac Intel crash in libpng-1.2.12 pnggccrd.c (v2) → Avoid Mac Intel crash in libpng-1.2.12 pnggccrd.c (v2) (checked in)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: