610715 - crash on Mac OS X [@ libSystem.B.dylib@0x4180 ][@ libSystem.B.dylib@0x4160 ][@ libSystem.B.dylib@0x45e0 ][@ libSystem.B.dylib@0x42b0 ][@ strlen]

Status: RESOLVED WORKSFORME

(Core Graveyard :: Plug-ins, defect)

Description

[Scoobidiver (away)]

It is a new crash signature. Crashes first appeared in 4.0b8pre/20101019 build.
It is #3 top crasher on Mac OS X in 4.0b8pre for the last week.
One comment talks about a Mac OS X update.

Signature	libSystem.B.dylib@0x4180
UUID	1b3f9cfa-d42b-4b5e-ab49-20cde2101109
Time 	2010-11-09 02:46:29.509108
Uptime	23
Last Crash	50 seconds before submission
Install Age	6933 seconds (1.9 hours) since version was first installed.
Product	Firefox
Version	4.0b8pre
Build ID	20101108033818
Branch	2.0
OS	Mac OS X
OS Version	10.6.4 10F569
CPU	amd64
CPU Info	family 6 model 15 stepping 13
Crash Reason	EXC_BAD_ACCESS / KERN_INVALID_ADDRESS
Crash Address	0x0
App Notes 	Renderers: 0x22600,0x20400

Frame 	Module 	Signature [Expand] 	Source
0 	libSystem.B.dylib 	libSystem.B.dylib@0x4180 	
1 	XUL 	nsPluginTag::RegisterWithCategoryManager 	nsCharTraits.h:629
2 	XUL 	nsPluginHost::ScanPluginsDirectory 	modules/plugin/base/src/nsPluginHost.cpp:2159
3 	XUL 	nsPluginHost::ScanPluginsDirectoryList 	modules/plugin/base/src/nsPluginHost.cpp:2187
4 	XUL 	nsPluginHost::FindPlugins 	modules/plugin/base/src/nsPluginHost.cpp:2275
5 	XUL 	nsPluginHost::LoadPlugins 	modules/plugin/base/src/nsPluginHost.cpp:2210
6 	XUL 	nsPluginHost::ReloadPlugins 	modules/plugin/base/src/nsPluginHost.cpp:457
7 	XUL 	nsWebNavigationInfo::IsTypeSupported 	docshell/base/nsWebNavigationInfo.cpp:93
8 	XUL 	nsDSURIContentListener::CanHandleContent 	docshell/base/nsDSURIContentListener.cpp:215
9 	XUL 	nsDocumentOpenInfo::TryContentListener 	uriloader/base/nsURILoader.cpp:709
10 	XUL 	nsDocumentOpenInfo::DispatchContent 	uriloader/base/nsURILoader.cpp:455
11 	XUL 	nsDocumentOpenInfo::OnStartRequest 	uriloader/base/nsURILoader.cpp:295
12 	XUL 	nsBaseChannel::OnStartRequest 	netwerk/base/src/nsBaseChannel.cpp:712
13 	XUL 	nsInputStreamPump::OnInputStreamReady 	netwerk/base/src/nsInputStreamPump.cpp:441
14 	XUL 	nsInputStreamReadyEvent::Run 	xpcom/io/nsStreamUtils.cpp:112
15 	XUL 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:609
16 	XUL 	NS_ProcessPendingEvents_P 	nsThreadUtils.cpp:200
17 	XUL 	nsBaseAppShell::NativeEventCallback 	widget/src/xpwidgets/nsBaseAppShell.cpp:131
18 	XUL 	nsAppShell::ProcessGeckoEvents 	widget/src/cocoa/nsAppShell.mm:399
19 	CoreFoundation 	CoreFoundation@0x4dd3c 	
20 	CoreFoundation 	CoreFoundation@0x4c088 	
21 	HIToolbox 	HIToolbox@0x2add3 	
22 	HIToolbox 	HIToolbox@0x151f8 	
23 	libSystem.B.dylib 	libSystem.B.dylib@0xa1fa 	
....

More reports  at:
http://crash-stats.mozilla.com/report/list?range_value=4&range_unit=weeks&signature=libSystem.B.dylib%400x4180&version=Firefox%3A4.0b8pre

Comment 1

[Carsten Book [:Tomcat]]

Top 21 Crash in Chofmann's Crash Stats list. Also Regression on Firefox 4Beta8pre and Beta7. Nominating Blocking

Comment 2

[Scoobidiver (away)]

> Top 21 Crash in Chofmann's Crash Stats list.
Crash stats must be done according to OS, because there are 50 times more users on Windows than on Mac OS X.
Mixing crash stats from different OS is a non sense, except if you add a throttle to correct the difference between users number.
It is now possible in crash stats for FF version (crashes per user reports) but not for OS.

Comment 3

[Carsten Book [:Tomcat]]

(In reply to comment #2)
> > Top 21 Crash in Chofmann's Crash Stats list.
> Crash stats must be done according to OS, because there are 50 times more users
> on Windows than on Mac OS X.
> Mixing crash stats from different OS is a non sense, except if you add a
> throttle to correct the difference between users number.
> It is now possible in crash stats for FF version (crashes per user reports) but
> not for OS.

well there is kind of a way to get a list/report when you click on count <OS> as example in http://crash-stats.mozilla.com/topcrasher/byversion/Firefox/4.0b8pre but i think your idea is also a good point

Comment 4

[Steven Michaud [:smichaud] (Retired)]

These crashes are all null-dereferences, and all seem to take place at
a call to strlen() on the following line:

http://hg.mozilla.org/mozilla-central/annotate/85b93f3ea9d1/xpcom/string/public/nsCharTraits.h#l629

There are no explicit references to nsCharTraits<char>.length() in
nsPluginTag::RegisterWithCategoryManager().  But there's lots of
string manipulation, and in particular lots of references to
'mMimeTypeArray[i]'.

Each element in mMimeTypeArray is filled using the new_str() inline
function, which can return NULL.  So I think there's a good chance
these crashes are triggered by one of the elements in mMimeTypeArray
being NULL.

Judging by the crash-stats figures, these crashes start happening with
the 2010-10-26-03-mozilla-central nightly, which implies the following
regression range:

2010-10-25-03-mozilla-central
2010-10-26-03-mozilla-central

http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2010-10-25+03%3A00%3A00&enddate=2010-10-26+03%3A00%3A00

The only patch in that range which changes plugin code is Scott
Greenlay's patch for bug 564485
(http://hg.mozilla.org/mozilla-central/rev/2bb53d0e9a64).  I think
there's a good chance that this patch triggered these crashes.

A simple fix would be to make new_str() return an empty string ("")
when it would normally return NULL.  But it's probably best to figure
out how/why some elements in mMimeTypeArray are being set to NULL.

Comment 5

[Scott Greenlay [:sgreenlay]]

Has this crash been seen on a build post http://hg.mozilla.org/mozilla-central/rev/6a2b0299996b (Nov 06 10:38:45)?

One problem fixed in that patch is that the mimetypes are assigned to the array based on info.fVariantCount rather than i (which used to leave empty array elements in fMimeTypeArray when it found invalid mimeString's).

Comment 6

[Steven Michaud [:smichaud] (Retired)]

> Has this crash been seen on a build post
> http://hg.mozilla.org/mozilla-central/rev/6a2b0299996b (Nov 06 10:38:45)?

Yes, unfortunately.  There are crashes up to yesterday's nightly (2010-11-09-03-mozilla-central).  (And it may be an accident that there aren't any listed for today's nightly.)

Comment 7

[Scott Greenlay [:sgreenlay]]

Attachment: WebPluginTypeEnabled support (v1.0)

I am not sure if this actually fixes the problem (since I can't reproduce it), but it is probably a good idea if we listen to Apple's WebPluginTypeEnabled key.

Comment 8

[Scott Greenlay [:sgreenlay]]

Comment on attachment 489624 [details] [diff] [review]
WebPluginTypeEnabled support (v1.0)

Moving the patch to bug 611136. However, this might solve the problem providing it is caused by an NULL mimetype coming from a disabled mimetype entry.

Comment 9

[Marcia Knous [:marcia]]

Do we think some of the other crash stacks such as http://crash-stats.mozilla.com/report/index/7e31037e-90a3-404b-84d7-6522f2101110 may be related?

Comment 10

[Steven Michaud [:smichaud] (Retired)]

Yes, this bug probably has crash stacks with other signatures.

Stacks with the signature libSystem.B.dylib are generally useless --
this is a system library, with many different methods in it.  It's
sheer luck that all (or most) of the current crashes at
libSystem.B.dylib@0x4180 are related.

All the libSystem.B.dylib@0x4180 crashes are on OS X 10.6.X.  But
that's very likely an accident -- the strlen() method is probably at a
different address on OS X 10.5.8.

> http://crash-stats.mozilla.com/report/index/7e31037e-90a3-404b-84d7-6522f2101110

The top few lines of this stack are a bit strange (and possibly
corrupted).  But the "signature" *is* strlen() (as you'd expect),
and the lower part is identical to the libSystem.B.dylib@0x4180
stacks.  So this is probably related.

Comment 11

[Marcia Knous [:marcia]]

Moving up in rank and now the #5 top crash in Beta 7.

Comment 12

[Marcia Knous [:marcia]]

Adding another similar stack since it shows up in the top ten of B7 data and will therefore get picked up in crash stats.

Comment 13

[timeless]

adding strlen to signature to remind people what's actually crashing...

Comment 15

[Johnny Stenback (:jst)]

This sounds like a high volume crash. Josh, giving this to you, but please feel free to reassign as needed.

Comment 16

[Johnny Stenback (:jst)]

Scott says he hasn't seen this in nightlies since the 15th, so maybe this got fixed? Can someone confirm?

Comment 17

[Steven Michaud [:smichaud] (Retired)]

The libSystem.B.dylib@0x4160 crash hasn't occurred in a build after
20101115030805.

But the libSystem.B.dylib@0x4180 crash hasn't occurred since the
20101113030748 build.

There aren't a whole lot of testers for the trunk nightlies, and the
latest crashing builds are only a few days old.  It may just be an
accident we haven't yet seen crashes with more recent builds.

The situation would be different, though, if we went a whole week
without crashes in newer builds.

Comment 18

[Johnny Stenback (:jst)]

Ok, let's wait and see then.

Comment 20

[Josh Aas]

This seems to have dropped off for beta8pre - can we close this out as fixed by the patch on bug 611136?

Comment 21

[Scoobidiver (away)]

> This seems to have dropped off for beta8pre - can we close this out as fixed by
> the patch on bug 611136?
I confirm it is closed whatever the crash signature.