the crash signature [@ shutdownhang | mozilla::CondVar::Wait | nsEventQueue::GetEvent | nsThread::nsChainedEventQueue::GetEvent] accounts for over 5% of browser crashes in 52.0b so far, but the analysis in https://bugzilla.mozilla.org/show_bug.cgi?id=1329966#c11 has shown that there are many different underlying issues that get lumped together in this one signature since firefox 52. that's likely due to the changes in bug 1306591. also see https://mozilla.github.io/stab-crashes/scomp.html?common=product%3DFirefox%26date%3D%3E2016-10-01%26submitted_from_infobar%3D%21__true__%26process_type%3Dbrowser%26signature%3D%5Eshutdownhang&p1=version%3D51.0b&p2=version%3D52.0b for the biggest changes in shutdownhang signatures from 51.0b compared to 52.0b. it would be great if we can find a way to split up this signature again...

[Tracking Requested - why for this release]: without this being resolved we might not find out about future regressions for shutdownhang crashes and have no good way to differentiate between crash reports with different underlying causes.

Commit pushed to master at https://github.com/mozilla/socorro https://github.com/mozilla/socorro/commit/288f1eb395503845f6076cd96adf8487ad200963 Bug 1338288 - Add nsThread::nsChainedEventQueue::GetEvent to the prefix signature list (#3674)

Marco, should this bug status be changed to resolved fixed ?

Yes, thanks for reminding me.

is the fix already live in production? ...because i don't see a drop in the [@ shutdownhang | mozilla::CondVar::Wait | nsEventQueue::GetEvent | nsThread::nsChainedEventQueue::GetEvent] signature yet: http://bit.ly/2mlaBsD

I think we may have reached the maximum number of splits ("|") in that case. Adrian, is there a maximum number of splits?

The most recent crash reports we have with signature `shutdownhang | mozilla::CondVar::Wait | nsEventQueue::GetEvent | nsThread::nsChainedEventQueue::GetEvent` are from March 1st, and that's when we pushed the change to prod. Since then, crash reports have correctly been assigned different signatures, like `shutdownhang | mozilla::CondVar::Wait | nsEventQueue::GetEvent | nsThread::nsChainedEventQueue::GetEvent | nsThread::GetEvent`. See for example: https://crash-stats.mozilla.com/search/?signature=%5Eshutdownhang%20%7C%20mozilla%3A%3ACondVar%3A%3AWait%20%7C%20nsEventQueue%3A%3AGetEvent%20%7C%20nsThread%3A%3AnsChainedEventQueue%3A%3AGetEvent&product=Firefox&date=%3E%3D2017-03-01T10%3A48%3A00.000Z&date=%3C2017-03-08T10%3A48%3A00.000Z&_sort=-date&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature If that is not the behavior you were asking for, please file a new bug. :) Marco, there is no limit to the number of parts in a signature. There is however a size limit, which is 255 characters.

I thought `nsThread::GetEvent` was in the skiplist, that's why I asked if there was a limit on the parts. I will add it to the skiplist.