700193 - crash [@ nsPNGEncoder::GetImageBufferSize]

Status: RESOLVED WORKSFORME

(Core :: Graphics: ImageLib, defect)

Description

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

From Soccorro: https://crash-stats.mozilla.com/report/index/c4021a4a-7e85-4f9f-a79e-028532111103

Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 	libmozalloc.so 	mozalloc_abort 	memory/mozalloc/mozalloc_abort.cpp:66
1 	libc.so 	libc.so@0x10d16 	
2 	libnspr4.so 	PR_Unlock 	nsprpub/pr/src/pthreads/ptsynch.c:237
3 		@0x5cf884ae 	
4 	libnspr4.so 	PR_Unlock 	nsprpub/pr/src/pthreads/ptsynch.c:237
5 	libnspr4.so 	PR_Unlock 	nsprpub/pr/src/pthreads/ptsynch.c:237
6 		@0x0 	
7 	libxul.so 	nsPNGEncoder::GetImageBufferSize 	image/encoders/png/nsPNGEncoder.cpp:215
8 	libxul.so 	NS_CancelAsyncCopy 	xpcom/io/nsStreamUtils.cpp:635
9 		@0x5cf5e19e 	
10 	libxul.so 	nsWindow::OnGlobalAndroidEvent 	widget/src/android/nsWindow.cpp:939
11 	libxul.so 	nsAppShell::ProcessNextNativeEvent 	widget/src/android/nsAppShell.cpp:421
12 	libxul.so 	nsBaseAppShell::DoProcessNextNativeEvent 	widget/src/xpwidgets/nsBaseAppShell.cpp:171
13 	libxul.so 	nsBaseAppShell::OnProcessNextEvent 	widget/src/xpwidgets/nsBaseAppShell.cpp:324
14 	libxul.so 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:595
15 	libxul.so 	NS_ProcessNextEvent_P 	obj-firefox/xpcom/build/nsThreadUtils.cpp:245
16 	libxul.so 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:110
17 	libxul.so 	MessageLoop::RunInternal 	ipc/chromium/src/base/message_loop.cc:208
18 	libxul.so 	MessageLoop::Run 	ipc/chromium/src/base/message_loop.cc:201
19 	libxul.so 	nsBaseAppShell::Run 	widget/src/xpwidgets/nsBaseAppShell.cpp:189
20 	libxul.so 	nsAppStartup::Run 	toolkit/components/startup/nsAppStartup.cpp:228
21 	libxul.so 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3547
22 	libxul.so 	Java_org_mozilla_gecko_GeckoAppShell_nativeRun 	toolkit/xre/nsAndroidStartup.cpp:141
23 	libmozutils.so 	Java_org_mozilla_gecko_GeckoAppShell_nativeRun 	other-licenses/android/APKOpen.cpp:232
24 	libdvm.so 	libdvm.so@0x11c76 	
25 	dalvik-LinearAlloc (deleted) 	dalvik-LinearAlloc @0x215612 	
26 	dalvik-heap (deleted) 	dalvik-heap @0x6eb52e 	
27 	libdvm.so 	libdvm.so@0x40f6d 	
28 	data@[e-mail]@classes.dex 	data@[e-mail]@classes.dex@0x22368 	
29 	libmozutils.so 	Java_org_mozilla_gecko_GeckoAppShell_nativeInit 	other-licenses/android/APKOpen.cpp:231
30 	dalvik-LinearAlloc (deleted) 	dalvik-LinearAlloc @0x215612 	
31 	libdvm.so 	libdvm.so@0x40f27 	
32 	dalvik-heap (deleted) 	dalvik-heap @0x6eb52e 	
33 	libdvm.so 	libdvm.so@0x46537 	
34 	dalvik-LinearAlloc (deleted) 	dalvik-LinearAlloc @0x215612 	
35 	data@[e-mail]@classes.dex 	data@[e-mail]@classes.dex@0x1590c 	
36 	dalvik-heap (deleted) 	dalvik-heap @0x6eb52e 	
37 	libdvm.so 	libdvm.so@0x11e3e 	
38 	libdvm.so 	libdvm.so@0x16e8a 	
39 	libdvm.so 	libdvm.so@0x1bd56 	
40 	libdvm.so 	libdvm.so@0x1bcc6 	
41 	dalvik-LinearAlloc (deleted) 	dalvik-LinearAlloc @0x273a 	
42 	libdvm.so 	libdvm.so@0x1ae12 	
43 	libdvm.so 	libdvm.so@0x16b06 	
44 	system@[e-mail]@classes.dex 	system@[e-mail]@classes.dex@0x99328 	
45 	dalvik-heap (deleted) 	dalvik-heap @0x91ca5e 	
46 	dalvik-LinearAlloc (deleted) 	dalvik-LinearAlloc @0x215abe 	
47 	dalvik-mark-stack (deleted) 	dalvik-mark-stack @0x4d5426e 	
48 	libdvm.so 	libdvm.so@0x9ef76 	
49 	libdvm.so 	libdvm.so@0x16b6a 	
50 	libdvm.so 	libdvm.so@0x16be2 	
51 	libdvm.so 	libdvm.so@0x16a8a 	
52 	libdvm.so 	libdvm.so@0x16ab2 	
53 	libdvm.so 	libdvm.so@0x16b06 	
54 	system@[e-mail]@classes.dex 	system@[e-mail]@classes.dex@0x8a3da 	
55 	system@[e-mail]@classes.dex 	system@[e-mail]@classes.dex@0x8a3b0 	
56 	system@[e-mail]@classes.dex 	system@[e-mail]@classes.dex@0x8a3b8 	
57 	org.mozilla.fennec-2.apk 	org.mozilla.fennec-2.apk@0x3fe2c4 	
58 	org.mozilla.fennec-2.apk 	org.mozilla.fennec-2.apk@0x4dc52d 	
59 	org.mozilla.fennec-2.apk 	org.mozilla.fennec-2.apk@0x4d87e0 	
60 	org.mozilla.fennec-2.apk 	org.mozilla.fennec-2.apk@0x4005c3 	
61 	org.mozilla.fennec-2.apk 	org.mozilla.fennec-2.apk@0x32ee28 	
62 	org.mozilla.fennec-2.apk 	org.mozilla.fennec-2.apk@0x3fea20 	
63 	org.mozilla.fennec-2.apk 	org.mozilla.fennec-2.apk@0x3fe018 	
64 	org.mozilla.fennec-2.apk 	org.mozilla.fennec-2.apk@0x37c93f

Comment 1

[Joe Drew (not getting mail)]

Brian, does this trigger anything in your mind?

Comment 2

[Brian R. Bondy [:bbondy]]

It's familiar ya but I'm not sure what the problem is without extra details or STR.

It's called like this:
PRUint32 imageBufferSize;
mContainedEncoder->GetImageBufferSize(&imageBufferSize);

And the implementation is straightforward:

// Returns the image buffer size
NS_IMETHODIMP nsPNGEncoder::GetImageBufferSize(PRUint32 *aOutputSize)
{
  NS_ENSURE_ARG_POINTER(aOutputSize);
  *aOutputSize = mImageBufferSize;
  return NS_OK;
}

Comment 3

[Glenn Randers-Pehrson]

This may depend on bug #392867.

Comment 4

[Brian R. Bondy [:bbondy]]

Well I think it is likely stack corruption because the call stack doesn't make sense.  I don't know if that's the cause though or if it is some other type of stack corruption.

Comment 5

[Glenn Randers-Pehrson]

Illegally returning from the png_error() replacement can cause stack corruption. That's why I think bug #392867 might be involved here.

Comment 6

[Brian R. Bondy [:bbondy]]

Ya gotcha, thnaks for linking them up.

Comment 7

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Str wanted, most likely a bad stack, need to have bug 392867 before we see the proper stack.  most likely should try to get the currently STR while it is busted so that we can see what the correct stack looks like when crashing.  Marking as P4 for now.

Comment 8

[Joe Drew (not getting mail)]

We should either not see this anymore, or see a much better stack, depending on whether this was a real bug or just a duplicate of bug 392867. Naoki, any data?

Comment 9

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Socorro doesn't report anything with this crash signature in the last 30 days.  I suppose we can just close this off as a duplicate?

Comment 10

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

or WFM might be better?

Comment 11

[Aaron Train [:aaronmt]]

yeah