941606 - Crash in xul!GCGraphBuilder::GCGraphBuilder

Status: RESOLVED WONTFIX

(Core :: XPCOM, defect)

Description

[Elbart]

Attachment: firefox-debug_0ef8_2013-11-21_14-29-59-237.log

Nightly 2013-11-20
Vista x86
Crashreport from a try without debugger:
https://crash-stats.mozilla.com/report/index/b9c967a0-37e9-48be-a83b-da4012131121
"Firefox 28.0a1 Crash Report [@ EMPTY: no crashing thread identified; ERROR_NO_MINIDUMP_HEADER ]"

Trying to load the GIF from https://bugzilla.mozilla.org/show_bug.cgi?id=523950#c11 crashes the browser after a few seconds.

In 25 the image fills up the virtual memory almost completely, but it doesn't crash the browser and the animation is shown.

Comment 1

[Elbart]

With build 20131127030201, and probably because of 943051 landing, I got a non-empty crashreport:
https://crash-stats.mozilla.com/report/index/d8c4e188-a490-493f-bf31-45c5d2131127

Comment 2

[Elbart]

Maybe it's not the correct one. Doesn't make much sense to have some HTML5-function involved when it's just a GIF.

Tried again with the default VM-limit, and this crash came along:
https://crash-stats.mozilla.com/report/index/7d15b0a3-f2f3-400a-88c4-ac5212131128

Comment 3

[Paul Silaghi, QA [:pauly]]

It didn't crash for me on 28.0a1 2013-12-03, Win 7 x64

Comment 4

[Tracy Walker [:tracy]]

This has spiked to #15 on on Nightly.

Comment 5

[Tracy Walker [:tracy]]

It's also 
#14 on 28beta
#26 on 29aurora

Comment 6

[Andrew McCreight [:mccr8]]

This is the failure of the allocation of a large hashtable, so I'm not entirely sure what can be done here, aside from fixing fragmentation.  Potentially, we could try to allocate a smaller hash table, but the next time the user closes a tab and we work to free it, we'll end up probably needing a larger hashtable anyways.

Comment 7

[Tracy Walker [:tracy]]

Startup crasher climbing higher to #8 on Nightly now.

Benjamin, who should we ping on this?

Comment 8

[Andrew McCreight [:mccr8]]

I looked at a bunch of stacks here, and they look bogus.  I think some binary addon is doing something bad:

CC_AbortIfNull(void *)
nsComponentManagerImpl::RegisterModule(mozilla::Module const *,mozilla::FileLocation *)
nsComponentManagerImpl::ManifestBinaryComponent(nsComponentManagerImpl::ManifestProcessingContext &,int,char * const *)

The component manager doesn't call into the cycle collector, so I'm guessing somehow a binary addon is passing in a code pointer value that happens to be inside the CC, somehow.

This is unrelated to the original issue filed in this bug, which is the cycle collector hitting an OOM condition.

Comment 9

[Andrew McCreight [:mccr8]]

I'll file a new bug about this binary component issue.

Comment 10

[Andrew McCreight [:mccr8]]

I filed bug 971888 for the top crash issue.

Comment 11

[Lukas Blakk [:lsblakk] use ?needinfo]

See comment in bug 971888 but as far as I can tell this is only an issue on Nightly and it will be resolved when we merge in ~4 weeks.  Nothing to track here, please correct me if I've overlooked something here.

Comment 12

[alex_mayorga]

FWIW my SO got this crash on 28 (bp-2103adc5-718a-413a-9b51-2e1a62140422) and 29.0.1 (bp-c01cf251-2acd-470e-acc8-e6e442140523) let me know in case you need something collected from a crashing profile...

Comment 13

[Sylvestre Ledru [:Sylvestre]]

Closing because no crash reported since 12 weeks.

Comment 14

[Sylvestre Ledru [:Sylvestre]]

Closing because no crash reported since 12 weeks.