a function for socorro to compare and show stacks of two or more crash reports, allowing for faster and more accurate determination of whether two stacks are the same, or how similar they are - with less eyestrain comparison could be a trivial straight out line-by-line of stack A and stack B same? line StackA StackB Y 1 abc - Y 2 def - N 3 xyz zyx ... Or more sophisticated comparison wherein it tries to match up as many frames as possible same? StackA StackB Y 1. abc 1. - Y 2. def 2. - N - 3. foobar Y 3. barfoo 4. barfoo N - 5. kazoo Y 4. xyz 6. xyz

Ah, this is the bug I was talking about, I think. We could offer this as a manual process, as described here, or run a complicated topcrash-like query to determine whether two stacks were similar.

yeah, this is the start of what we need for "smart analysis" one kind of pattern we need to look for is zzz xxx xxx xxx xxx abc abc abc def def def ghi ghi ghi yyy yyy yyy where abc def ghi is the offending code, and some times it just takes longer for the crash to occur so there might be some code execution after the problem sets in..

another case is sorting out several problems from one stack signature like in https://bugzilla.mozilla.org/show_bug.cgi?id=422823 in that single stack signature we have a variety of bugs.. some *might* be connected like example 1 and 2 below that deal with menu system code, and some might be entirely different areas like layout, but they all end up crashing in an OS library... so we need a bit more precision and depth to the stack signature name. maybe for this post processing we add the "address" field as part of the signature nsObjCExceptionLogAbort(NSException*) + address 0x1017eb8 0 XUL nsObjCExceptionLogAbort mozilla/toolkit/xre/MacApplicationDelegate.mm:63 1 XUL -[MacApplicationDelegate applicationDockMenu:] mozilla/toolkit/xre/MacApplicationDelegate.mm:265 2 AppKit AppKit@0x2b5467 3 AppKit AppKit@0x120586 4 HIServices HIServices@0x1e2c1 5 HIServices HIServices@0x1e227 6 HIServices HIServices@0x49ff 7 HIServices HIServices@0x4918 8 CoreFoundation CoreFoundation@0x322f4 9 CoreFoundation CoreFoundation@0x22594 10 CoreFoundation CoreFoundation@0x21a35 nsObjCExceptionLogAbort(NSException*) + address 0x13c2e0c 0 XUL nsObjCExceptionLogAbort mozilla/widget/src/cocoa/nsMenuX.mm:63 1 XUL nsMenuX::RemoveAll mozilla/widget/src/cocoa/nsMenuX.mm:422 2 XUL nsMenuX::~nsMenuX mozilla/widget/src/cocoa/nsMenuX.mm:111 3 XUL nsMenuX::Release mozilla/widget/src/cocoa/nsMenuX.mm:87 4 XUL ReleaseObjects nsCOMArray.cpp:151 5 XUL nsVoidArray::EnumerateForwards nsVoidArray.cpp:678 6 XUL nsCOMArray_base::Clear nsCOMArray.cpp:158 7 XUL nsMenuBarX::~nsMenuBarX mozilla/widget/src/cocoa/nsMenuBarX.mm:217 8 XUL nsMenuBarX::Release mozilla/widget/src/cocoa/nsMenuBarX.mm:67 9 XUL nsCOMPtr_base::~nsCOMPtr_base nsCOMPtr.cpp:81 10 XUL nsCocoaWindow::~nsCocoaWindow mozilla/widget/src/cocoa/nsCocoaWindow.mm:542 nsObjCExceptionLogAbort(NSException*) + address 0x13c2e0c 0 XUL nsObjCExceptionLogAbort mozilla/widget/src/cocoa/nsCocoaWindow.mm:63 1 XUL nsCocoaWindow::Show mozilla/widget/src/cocoa/nsCocoaWindow.mm:806 2 XUL nsView::SetVisibility mozilla/view/src/nsView.cpp:473 3 XUL nsViewManager::SetViewVisibility mozilla/view/src/nsViewManager.cpp:1741 4 XUL nsMenuPopupFrame::AdjustView mozilla/layout/xul/base/src/nsMenuPopupFrame.cpp:329 5 XUL nsPopupSetFrame::DoLayout mozilla/layout/xul/base/src/nsMenuBarListener.cpp:213 6 XUL nsIFrame::Layout mozilla/layout/xul/base/src/nsBox.cpp:561 7 XUL nsSprocketLayout::Layout mozilla/layout/xul/base/src/nsSprocketLayout.cpp:523 thats something like is done for http://talkback-public.mozilla.org/reports/firefox/FF20013/smart-analysis.all

See also bug 512910.

Still wanted?

yes.

I don't think this is a scoped task which we can directly prioritize. If somebody wants to work on prototyping smarter analysis of common stacks, I'm happy to help you get started using mapreduce jobs. Until then, let's not track this.

(In reply to Benjamin Smedberg [:bsmedberg] from comment #7) > I don't think this is a scoped task which we can directly prioritize. Please give more detail - I don't understand what this means. Does it mean there is not enough information here to spec a solution? And if so, why not ask for me info rather than just close.

Conversely, is what's requested here covered by bug 512910

One of my priorities is exposing raw bug data to the public in a machine-readable way, so that anyone can build a stack-comparison tool to suit their needs. As it stands, comparing just two stacks is rarely sufficient, and classifying many stacks requires something like bug 512910 (which I purposefully still left open, although any really good solution is going to require significant amounts of work). So whether this is WONTFIX or just INCOMPLETE, I don't think it's a task that the Socorro team should currently track, which is why I closed it.