Currently, mozalloc_abort crash signature is #1 top crasher in 4.0b11. There are 3 opened bugs but lots are missing. It is a follow-up of bug 630230. Please add the following items to prefixSignatureRegEx: mozalloc_abort* mozcrt19.dll@0x*

I think mozcert19.dll should simply be on the skiplist: the address is going to change for every build, so it's not going to make useful signatures.

lars, can you check this patch and take the bug?

Why there is a "." at the end of mozalloc_abort? mozalloc_abort(char const* const)won't be detected.

It's a regex, not a glob.

argh, the skiplist is wrong, it ought to be 'mozcrt19.dll@0x.*'

Comment on attachment 511382 [details] [diff] [review] mozalloc_abort in prefixlist, mozcrt in skiplist, rev. 1.1 this looks fine. I've introduced it to the 1.7.7 code line. I'm filing an IT bug to have it added to the 1.7.6 system in production.

In reply to comment 1 > I think mozcert19.dll should simply be on the skiplist: the address is going to > change for every build, so it's not going to make useful signatures. For information, the mozcrt19.dll version is 8.0.0.0 in 3.6, 4.0 Beta 11 and Minefield, so crash signatures don't move so much. Why mozcrt19.dll and mozcpp19.dll instead of mozcrt20.dll and mozcpp20.dll?

Because it's just not worth the churn of changing it.

this is now in production. If you notice problems or anomalies, please re-open this bug or file a new one.

The mozcrt19.dll@0x* looks like it ended up in the prefix list instead of the skip list: mozalloc_abort(char const* const) | mozcrt19.dll@0x1327f | nsCycleCollectorGCHookRunnable::Run() is now on the topcrash list: https://crash-stats.mozilla.com/query/query?product=Firefox&version=Firefox%3A4.0b11&range_value=1&range_unit=hours&date=02%2F10%2F2011+16%3A56%3A11&query_search=signature&query_type=exact&query=&build_id=&process_type=browser&hang_type=crash&do_query=1 whereas I'd have expected the signature to be mozalloc_abort(char const* const) | nsCycleCollectorGCHookRunnable::Run() based on the description in this bug. Or was that the expected behavior from that patch?

(Might IT have applied patch 1 instead of 1.1?)

The applied patch was correct and is producing the results that I expect. I think there is a misunderstanding on how signature generation works. 'irrelevantSignatureRegEx' is used only to trim down to the first "interesting" frame signature in the stack. From that point the 'prefixSignatureRegEx' matches accumulate until there is a frame signature that is completely unknown. The processor always produces signatures made from contiguous frame signatures. It never edits frame signatures out of the middle, even if those frames match the 'irrelevantSignatureRegEx'. This method was debated during the original implementation and no consensus was reached. We made the decision to go with this technique until it was proven to be inadequate. We can revisit this decision at anytime.

ok yeah, we really need to remove the mozcrt19.dll frames from the middle of this signature. I'm not sure why we don't have better symbols for them (perhaps PGO), but they are making it very hard to correlate the mozalloc_abort signatures.

I need to split this issue off into a new bug. The solution will require reworking the signature generation routines in the processor. I will have created Bug 633527 to address this issue.

the code to apply the 'irrelevantSignatureRegEx' throughout the signature generation process has been committed to 1.7.7 trunk.