696906 - crash [@ mozalloc_abort | nsTextFrame::BuildDisplayList]

Status: RESOLVED INVALID

(Core :: Layout, defect)

Description

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

This bug was filed from the Socorro interface and is 
report bp-4c5540d1-206e-40c8-b266-96ce22111019 .
============================================================= 
Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 	libmozalloc.so 	mozalloc_abort 	memory/mozalloc/mozalloc_abort.cpp:66
1 	libc.so 	libc.so@0x1a122 	
2 	libxul.so 	nsTextFrame::BuildDisplayList 	layout/base/nsDisplayList.h:572
3 		@0x79614c72 	
4 	libxul.so 	nsCharSeparatedTokenizerTemplate<IsSVGWhitespace>::nextToken 	nsCharSeparatedTokenizer.h:164
5 		@0x79614c62 	
6 	libxul.so 	nsSliderFrame::AttributeChanged 	layout/xul/base/src/nsSliderFrame.c

#1 crash in Aurora (9)

More signatures : https://crash-stats.mozilla.com/report/list?range_value=7&range_unit=days&date=2011-10-24%2007%3A00%3A00&signature=mozalloc_abort%20%7C%20nsTextFrame%3A%3ABuildDisplayList&version=Fennec%3A9.0a2

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to Naoki Hirata :nhirata from comment #0)
> This bug was filed from the Socorro interface and is 
> report bp-4c5540d1-206e-40c8-b266-96ce22111019 .
> ============================================================= 
> Crashing Thread
> Frame 	Module 	Signature [Expand] 	Source
> 0 	libmozalloc.so 	mozalloc_abort 	memory/mozalloc/mozalloc_abort.cpp:66
> 1 	libc.so 	libc.so@0x1a122 	
> 2 	libxul.so 	nsTextFrame::BuildDisplayList 	layout/base/nsDisplayList.h:572
> 3 		@0x79614c72 	
> 4 	libxul.so 	nsCharSeparatedTokenizerTemplate<IsSVGWhitespace>::nextToken 
> nsCharSeparatedTokenizer.h:164
> 5 		@0x79614c62 	
> 6 	libxul.so 	nsSliderFrame::AttributeChanged 
> layout/xul/base/src/nsSliderFrame.c

This stack is pretty much incomprehensible -- I don't see how any of the alleged frames have any reasonable relationship to their neighbors -- though I didn't check all the non-neighboring combinations.  Are there any known bugs on getting breakpad to produce correct stacks for Android?

> #1 crash in Aurora (9)

By which you mean a single user crashed a large number of times in a 15 minute period, probably doing the same thing repeatedly?

Comment 2

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

dbaron, yes, that is true.  It could be the same crash, but I'm not certain if they are doing the same thing over and over again.  The uptime is different; mostly short times 1~28 seconds uptime; with an exception of 169 sec uptime.

Is there anything about break pad and handling virtual methods (on android)?

There are some bugs about getting the correct stack, but none of them address bugs on getting breakpad to produce correct stacks for android.  See: bug 696637, bug 623335

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I filed bug 697301 on the lack of useful stacks in this case.

I don't think there's anywhere close to enough information in this bug to investigate a crash, since:
 (1) there's no usable stack
 (2) there are no steps to reproduce or any other hint as to the cause

Given that it looks like one user crashing a bunch of times, I don't think it's worth the effort of manually debugging minidumps.  If there were more evidence of prevalence it might be worth doing so (though on non-Windows platforms such debugging would, as far as I can tell, be an extremely manual process).

Additionally, if the stacks are fixed, this bug will likely show up with a different signature and no way to connect it to this particular bug report.

Therefore, I don't think there's any useful action to take here, so I'm going to mark this report as INVALID.