I was looking at RtlpWaitOnCriticalSection crashes and found a bunch of different stacks: RtlpWaitOnCriticalSection | RtlpDeCommitFreeBlock | drwebsp.dll@0x58e1 RtlpWaitOnCriticalSection | RtlpAllocateAffinityIndex | drwebsp.dll@0x58e1 RtlpWaitOnCriticalSection | EtwEventEnabled | drwebsp.dll@0x58e1 RtlpWaitOnCriticalSection | RtlpFreeHandleForAtom | NPSWF32.dll@0x3b2cb RtlpWaitOnCriticalSection | EtwEventEnabled | imon.dll@0x44dd RtlpWaitOnCriticalSection | RtlQueryPerformanceFrequency | nvLsp.dll@0x5ced RtlpWaitOnCriticalSection | RtlAddAccessAllowedAce | drwebsp.dll@0x58e1 They clearly shouldn't all be grouped under the signature "RtlpWaitOnCriticalSection". The weird thing is that even among the drwebsp.dll@0x58e1 crashes, the second line of the stack is often different. So maybe it would be best to skip these ntdll.dll functions (or all ntdll.dll functions?) rather than append them, so the signatures are just e.g. "drwebsp.dll@0x58e1". (Having a fix for bug 512910 sure would be nice, too!)

i'd rather drop RtlpWaitOnCriticalSection and have the one remaining ntdll + the caller. *Free* is a memory thing, but EtwEventEnabled is unrelated.

So you want these to appear as RtlpDeCommitFreeBlock | drwebsp.dll@0x58e1 RtlpAllocateAffinityIndex | drwebsp.dll@0x58e1 EtwEventEnabled | drwebsp.dll@0x58e1 RtlpFreeHandleForAtom | NPSWF32.dll@0x3b2cb EtwEventEnabled | imon.dll@0x44dd RtlQueryPerformanceFrequency | nvLsp.dll@0x5ced RtlAddAccessAllowedAce | drwebsp.dll@0x58e1 sounds good to me.

Here's a complete list of exports from ntdll.dll on my Windows 7 RC system. I don't know how thorough you want to be on this.

Jesse: can you summarize exactly what we want here so Lars can add it to the config?

Skip these two: RtlpWaitOnCriticalSection RtlpWaitForCriticalSection Append all other ntdll.dll functions, or if that's hard, these six: RtlpDeCommitFreeBlock RtlpAllocateAffinityIndex EtwEventEnabled RtlpFreeHandleForAtom RtlQueryPerformanceFrequency RtlAddAccessAllowedAce (Can we make rules based on dll, or only based on function name?)

As currently implemented, this is purely based on function name: http://code.google.com/p/socorro/source/browse/trunk/socorro/processor/processor.py#313 Seems like a reasonable enhancement request to make it by module as well, though.

Given bug 511759 comment 8 and that bug's blocking1.9.2+ flag, I think this needs to be a blocker as well.

Frank/Lars - can we look at modifying our signature algorithm to handle this case?

top crash analysis for 3.6 blocker bug 511759 and maybe more depends on this going in.

Discussed in CrashKill 11/9 meeting. Updating to blocker.

We can make frames with these names always be a prefix for subsequent frame names: EtwEventEnabled Rtlp(FreeHandleForAtom|DeCommitFreeBlock|AllocateAffinityIndex) Rtl(AddAccessAllowedAce|QueryPerformanceFrequency) RtlpWait(On|For)CriticalSection # line 4 There is no existing way to remove items in # line 4 from the front of the signature without also removing them farther in. If this will be satisfactory, I can submit an IT bug to have it done.

As soon as some developer OK's using all of these as prefix, will ask IT to... in the file scripts/config/processorconfig.py: replace prefixSignatureRegEx.default = (what is now there) with prefixSignatureRegEx.default = '@0x0|strchr|strstr|strlen|PL_strlen|strcmp|wcslen|memcpy|memmove|memcmp|malloc|realloc|.*free|arena_dalloc_small|arena_alloc|arena_dalloc|nsObjCExceptionLogAbort(\(.*?\))0,1}|libobjc.A.dylib@0x1568.|nsCOMPtr_base::assign_from_qi(nsQueryInterface,nsIDconst&)|objc_msgSend|RaiseException|_purecall|nsTArray_base::ShiftData(unsigned int, unsigned int, unsigned int, unsigned int)|PL_DHashTableOperate|EtwEventEnabled|RtlpFreeHandleForAtom|RtlpDeCommitFreeBlock|RtlpAllocateAffinityIndex|RtlAddAccessAllowedAce|RtlQueryPerformanceFrequency|RtlpWaitOnCriticalSection|RtlpWaitForCriticalSection (avoiding line breaks that may be inserted by bugzilla)

See also bug 511758: Fix at same time

This sounds perfect, per comment 5.

fyi: IT bug 529076 filed 2009-11-16 11:40 PST by Frank Griswold [:griswolf] [:fgriswold]

Damon: does this block the release of 1.9.2? I'd think not, though obviously very much desired.

per 529076: Fixed at 2009-11-18 16:07:48 PST