264734 - talkback data for ff branch has low quality

Status: RESOLVED WORKSFORME

(Core Graveyard :: Talkback Client, defect)

Description

[Bernd]

I searched for nsTable for three different products and the ff talkbacks are not
very usefull. This is a limited sample and I might be wrong but my impression is
that the talkback data on ff are somehow flawed. 

search for nsTable in FireFoxtrunk

three matches:

1317151  nsTableFrame::BalanceColumnWidths 450cc8d4                            
                     bogus stacktrace
1226389  nsTableRowGroupFrame::UndoContinuedRow() 2a4972df  	                  
        bug   263738
1163001  nsTableOuterFrame::Reflow 02e6d7c9                                    
                                bogus stacktrace

search for nsTable in MozillaTrunk
1344203       nsTableOuterFrame::OuterReflowChild() c29b88ee                   
                   bug 264620
1341947       nsTableCellMap::DeleteRightBottomBorders eb64a6ed                
              valid stacktrace no bug yet
1335249  	 nsTableOuterFrame::OuterReflowChild                                 
                           bug 264620
1335187  	 nsTableOuterFrame::OuterReflowChild                                 
                           bug 264620
1301939  	 nsTableRowGroupFrame::UndoContinuedRow                              
               bug  263738
1272983  	 nsTableOuterFrame::OuterReflowChild                                 
                           bug 264620
1248576  	 nsTableFrame::OrderRowGroups() a094b3f5                             
                     bogus stacktrace
1246744  	 nsTableRowGroupFrame::UndoContinuedRow 6947a4b9                     
     bug  263738
... repeat 11 times
1018914  	 nsTableFrame::GetFrameAtOrBefore                                    
                            valid stacktrace bug 264733 for an assert

search for nsTable in FireFox1.0
1350411  	 nsTableRowFrame::CalculateCellActualSize() 5981f36c                 
           the last entry is bogus
1350124  	 nsTableFrame::GetEffectiveColSpan e02e1173                          
                  bogus stacktrace
1349577  	 nsTableRowFrame::IR_TargetIsChild bef0bf12                          
                   bogus stacktrace
1349402  	 nsTableCellFrame::Reflow 88d6599c                                   
                              valid stacktrace, but no place to crash
1349339  	 nsTableRowFrame::IncrementalReflow cbdef0c8                         
               valid stacktrace, but no place to crash
1337643  	 nsTableOuterFrame::Paint 868d20dc                                   
                              valid stacktrace no bug yet
1336434  	 nsTableFrame::GetTableFrame a887ed6d                                
                       valid stacktrace no bug yet
1336197  	 nsTableOuterFrame::`vftable' 84fe7925                               
                             bogus stacktrace
1336069  	 nsTableOuterFrame::BalanceLeftRightCaption 15abf695                 
         bogus stacktrace
1335740  	 nsTableOuterFrame::BalanceLeftRightCaption 97838ad7                 
        bogus stacktrace

Comment 1

[Boris Zbarsky [:bzbarsky]]

The bogus backtraces are really worrisome -- those would prevent us from
finding/fixing the real crash....

Comment 2

[Jay Patel [:jay]]

I remember Bryner was talking about possibly disabling some of the items we
collect.  I wonder if he made any changes on the server side that are creating a
master.ini for the latest builds that doesn't work properly.

Comment 3

[Jay Patel [:jay]]

I checked the server side config and everything is the same as it has always
been, so I don't think any changes on the Talkback server side are the problem.

And just to better understand the issue here, by "bogus stacktrace", do you mean
the stack signature, source line and no. are pointing to the wrong place?  Or is
it just that the stacks are fairly short and therefore not as useful as a more
complete stack?

I know we have had some weird results for a lot of crashes over the years, so it
might just be that Talkback is not getting all the information it needs and
therefore is not able to build a complete stack for these crashes. 

Hopefully we can continue to gather more information and possibly find the cause
of this behavior.

Comment 4

[Bernd]

What bothers me are the places where the crashes occure, one would expect that
they reassemble the trunk crashes, but they dont. Neither do the "usual
suspects" show up, its just the impression that ff crashes and one gets a random
stacktrace. I did call one line stacktraces bogus.

Comment 5

[Jay Patel [:jay]]

Looking at the latest Firefox 1.0 data, we seem to getting good data.  Marking
this worksforme for now.