Closed Bug 354997 Opened 18 years ago Closed 18 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: 18 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: 18 years ago → 18 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: