Closed Bug 421119 Opened 12 years ago Closed 7 years ago

function for socorro to compare stacks of two or more crash reports

Categories

(Socorro :: General, task, P3, minor)

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: wsmwk, Unassigned)

References

Details

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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
Blocks: 418386
See also bug 512910.
Severity: enhancement → minor
Priority: -- → P3
Target Milestone: --- → 2.1
Target Milestone: 2.1 → 2.2
Target Milestone: 2.2 → 2.3
Target Milestone: 2.3 → 2.3.1
Target Milestone: 2.3.1 → 2.3.2
Target Milestone: 2.3.2 → ---
Component: Socorro → General
Product: Webtools → Socorro
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.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
(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.
Flags: needinfo?(benjamin)
Conversely, is what's requested here covered by bug 512910
Flags: needinfo?(chofmann)
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.
Flags: needinfo?(chofmann)
Flags: needinfo?(benjamin)
You need to log in before you can comment on or make changes to this bug.