Closed Bug 264734 Opened 20 years ago Closed 20 years ago

talkback data for ff branch has low quality

Categories

(Core Graveyard :: Talkback Client, defect)

Product:
Core Graveyard
Component:
Talkback Client
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: bernd_mozilla, Assigned: jay)

Details

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
The bogus backtraces are really worrisome -- those would prevent us from finding/fixing the real crash....
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.
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.
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.
Looking at the latest Firefox 1.0 data, we seem to getting good data. Marking this worksforme for now.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.