602102 - Crash in [@ NS_TableDrivenQI]

Status: NEW

(Core :: XPCOM, defect)

Description

[Marcia Knous [:marcia]]

Seen while reviewing crash stats. http://tinyurl.com/2elksl7 to the crashes which are all Windows. Crashes started showing up using today's build, 2010100500. Several of the reports mention justin.tv.

Frame 	Module 	Signature [Expand] 	Source
0 	xul.dll 	NS_TableDrivenQI 	obj-firefox/xpcom/build/nsISupportsImpl.cpp:49
1 	xul.dll 	nsNSSSocketInfo::QueryInterface 	security/manager/ssl/src/nsNSSIOLayer.cpp:256
2 	xul.dll 	nsSSLIOLayerAddToSocket 	security/manager/ssl/src/nsNSSIOLayer.cpp:3786
3 	xul.dll 	nsSSLIOLayerNewSocket 	security/manager/ssl/src/nsNSSIOLayer.cpp:2402
4 	xul.dll 	nsSSLSocketProvider::NewSocket 	security/manager/ssl/src/nsSSLSocketProvider.cpp:72
5 	xul.dll 	nsSocketTransport::BuildSocket 	
6 	xul.dll 	nsSocketTransport::InitiateSocket 	netwerk/base/src/nsSocketTransport2.cpp:1119
7 	xul.dll 	nsSocketTransport::OnSocketEvent 	netwerk/base/src/nsSocketTransport2.cpp:1454
8 	xul.dll 	nsSocketEvent::Run 	netwerk/base/src/nsSocketTransport2.cpp:98
9 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:547
10 	xul.dll 	NS_ProcessNextEvent_P 	obj-firefox/xpcom/build/nsThreadUtils.cpp:250
11 	xul.dll 	nsSocketTransportService::Run 	netwerk/base/src/nsSocketTransportService2.cpp:589
12 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:547
13 	xul.dll 	nsThread::ThreadFunc 	xpcom/threads/nsThread.cpp:263
14 	nspr4.dll 	_PR_NativeRunThread 	nsprpub/pr/src/threads/combined/pruthr.c:426
15 	nspr4.dll 	pr_root 	nsprpub/pr/src/md/windows/w95thred.c:122
16 	mozcrt19.dll 	_callthreadstartex 	obj-firefox/memory/jemalloc/crtsrc/threadex.c:348
17 	mozcrt19.dll 	_threadstartex 	obj-firefox/memory/jemalloc/crtsrc/threadex.c:326
18 	kernel32.dll 	BaseThreadStart

Comment 1

[chris hofmann]

this has risen quickly to #7 topcrash on trunk with 27 crashes yesterday.  Its been around at #233 on b6 and #398 on 3.6.10.   Its possible there is a new volume regression on trunk, but it also looks like there might be several dups that are inflating the daily numbers here.  series of crashes around 11:56-12:12 and around 14:36 all from same OS and other fingerprinting characteristics.  lets watch this closely to see if volume continues.  the nomination can be removed if the volume drops in the next few days.


checking --- NS_TableDrivenQI.void...QITableEntry.const...nsID.const...void... 20101005-crashdata.csv
found in: 3.6.10 4.0b7pre 4.0b6 3.6.3 3.6.8 3.6b1 3.5 3.6.9 3.6.6 3.6 3.5.13 3.5.11 3.5.1 3.0.5
release total-crashes
              NS_TableDrivenQI.void...QITableEntry.const...nsID.const...void... crashes
                         pct.
all     354642  101     0.000284794
3.6.10  212461  36      0.000169443
4.0b7pre2643    27      0.0102157
4.0b6   25108   9       0.000358451
3.6.3   11116   8       0.000719683
3.6.8   18346   4       0.000218031
3.6b1   605     3       0.00495868
3.5     970     3       0.00309278
3.6.9   3418    2       0.000585138

Comment 2

[chris hofmann]

looking closer at the 4.0b7pre urls the 27 total crashes might be reduced to about 9 unique crashes with the distribution of the dups looking like below.  all the activity seemed to be on brazillian sites:

   8 4.0b7pre https://www.google.com/accounts/ServiceLogin?service=orkut
   4 4.0b7pre http://pt-br.justin.tv/mastertv670
   3 4.0b7pre http://pt-br.justin.tv/tvgol111111111
   3 4.0b7pre http://globoesporte.globo.com/volei/
   3 3.6.10 \N
   2 4.0b7pre http://www.naointendo.com.br/
   2 4.0b7pre http://pt-br.justin.tv/tve_tvelectro41
   2 4.0b7pre http://pt-br.justin.tv/chat/embed?channel=mastertv670&popout_chat=true
   2 4.0b7pre http://globoesporte.globo.com/

Comment 3

[Benjamin Smedberg]

Marcia or chofmann, there are many different crashes lurking under this signature. We need a way to break it down by stuff lower in the stack.

I see at least these things in various stacks with this signature:

* nsPluginInstanceOwner::StartTimer
* nsGenericHTMLElement::SetClassName
* nsFrameManager::CaptureFrameState
* nsSHEntry::QueryInterface
* nsUrlClassifierHashCompleter::QueryInterface
* nsErrorService::QueryInterface

Each of these probably has a different regression range and needs to be tracked separately. As it is, this meta-bug doesn't block.

Comment 4

[Wayne Mery (:wsmwk)]

>50% are startup

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

Crash volume for signature 'NS_TableDrivenQI':
 - nightly (version 50): 20 crashes from 2016-06-06.
 - aurora  (version 49): 59 crashes from 2016-06-07.
 - beta    (version 48): 434 crashes from 2016-06-06.
 - release (version 47): 715 crashes from 2016-05-31.
 - esr     (version 45): 79 crashes from 2016-04-07.

Crash volume on the last weeks:
            W. N-1  W. N-2  W. N-3  W. N-4  W. N-5  W. N-6  W. N-7
 - nightly       1       5       2       3       0       1       3
 - aurora       11       3       4       8       6      13      12
 - beta        152      65      30      58      66      27      18
 - release      90      79     114      79     100      79     109
 - esr           9       9       1       6      15       8       1

Affected platforms: Windows, Mac OS X, Linux

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

Crash volume for signature 'NS_TableDrivenQI':
 - nightly (version 51): 2 crashes from 2016-08-01.
 - aurora  (version 50): 16 crashes from 2016-08-01.
 - beta    (version 49): 162 crashes from 2016-08-02.
 - release (version 48): 81 crashes from 2016-07-25.
 - esr     (version 45): 97 crashes from 2016-05-02.

Crash volume on the last weeks (Week N is from 08-22 to 08-28):
            W. N-1  W. N-2  W. N-3
 - nightly       2       0       0
 - aurora        1       7       8
 - beta         54      64      19
 - release      21      28      15
 - esr           5       6       8

Affected platforms: Windows, Mac OS X, Linux

Crash rank on the last 7 days:
           Browser   Content     Plugin
 - nightly           #365
 - aurora
 - beta    #454      #572
 - release #802
 - esr     #3378

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

Crash volume for signature 'NS_TableDrivenQI':
 - nightly (version 52): 7 crashes from 2016-09-19.
 - aurora  (version 51): 4 crashes from 2016-09-19.
 - beta    (version 50): 72 crashes from 2016-09-20.
 - release (version 49): 144 crashes from 2016-09-05.
 - esr     (version 45): 90 crashes from 2016-06-01.

Crash volume on the last weeks (Week N is from 10-03 to 10-09):
            W. N-1  W. N-2
 - nightly       0       7
 - aurora        4       0
 - beta         35      37
 - release     107      37
 - esr           8       5

Affected platforms: Windows, Mac OS X, Linux

Crash rank on the last 7 days:
           Browser   Content     Plugin
 - nightly
 - aurora  #1066     #275
 - beta    #450      #573
 - release #613      #341
 - esr     #836

Comment 8

[Richard Leger]

FYI and reference... if that can help in any way...

Thunderbird 45.5.1 Crash Report [@ NS_TableDrivenQI ]
Note: End-user was closing tab of an email openened via global search history
bp-fc92cf28-da8b-4f83-b8bb-403272161208     08/12/2016    15:21 MM
https://crash-stats.mozilla.com/report/index/fc92cf28-da8b-4f83-b8bb-403272161208
ØKERNELBASE.dll         6.1.7601.23569         559826121FFA46DFA4A74D1AF319182C1 wkernelbase.pdb
kernel32.dll         6.1.7601.23569         AB6B617AB7E1496AB63555DEBF8A91B12 wkernel32.pdb

Thunderbird 45.4.0 Crash Report [@ NS_TableDrivenQI ]
Note: End-user navigating between Thunderbird email folders in an IMAP account between Archives,Sent and TB crashed when clicked on Inbox and then it crashed...
bp-b7c4a34c-deba-461d-9252-2b0c12161118 18/11/2016    11:38 MM
https://crash-stats.mozilla.com/report/index/b7c4a34c-deba-461d-9252-2b0c12161118
kernel32.dll         6.1.7601.23569         AB6B617AB7E1496AB63555DEBF8A91B12 wkernel32.pdb
ntdll.dll         6.1.7601.23569         E8115772097C49E1B552D29E17AD30DD2         wntdll.pdb

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

Crash volume for signature 'NS_TableDrivenQI':
 - nightly (version 53): 675 crashes from 2016-11-14.
 - aurora  (version 52): 187 crashes from 2016-11-14.
 - beta    (version 51): 170 crashes from 2016-11-14.
 - release (version 50): 660 crashes from 2016-11-01.
 - esr     (version 45): 226 crashes from 2016-07-06.

Crash volume on the last weeks (Week N is from 01-02 to 01-08):
            W. N-1  W. N-2  W. N-3  W. N-4  W. N-5  W. N-6  W. N-7
 - nightly       8      57      96      12     175     207     118
 - aurora        4       5      12       6      20     140       0
 - beta         23      30      10      31      43      25       4
 - release      96      94     111     110     104      82      34
 - esr           7       1      12      34      16      20      13

Affected platforms: Windows, Mac OS X, Linux

Crash rank on the last 7 days:
           Browser   Content   Plugin
 - nightly #81       #14
 - aurora  #380      #44
 - beta    #595      #483
 - release #657      #632
 - esr     #829

Comment 10

[Julien Cristau [:jcristau]]

Too late for firefox 52, mass-wontfix.

Comment 11

[Wayne Mery (:wsmwk)]

I doubt the bulk of crashes, few that they are (<90/week for Firefox), are actionable. bp-73534204-552a-4732-a98f-1ff910210220, 0 seconds, is an example.

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

The bug is linked to a topcrash signature, which matches the following criterion:

• Top 10 AArch64 and ARM crashes on release (startup)

For more information, please visit auto_nag documentation.

Comment 13

[Andrew McCreight [:mccr8]]

This has spiked up, but it looks entirely due to a single installation that has crashes more than 400 times.

Here's one of those crashes: bp-7b6e4d72-b628-4ce8-b123-b2d900230404

The stack has nsInputStreamChannel::QueryInterface(), but not much else.

Comment 14

[Nika Layzell [:nika] (ni? for response)]

This seems unactionable, and like we should perhaps just add it to the prefix list.

Comment 15

[BugBot [:suhaib / :marco/ :calixte]]

Based on the topcrash criteria, the crash signature linked to this bug is not a topcrash signature anymore.

For more information, please visit auto_nag documentation.

Comment 16

[Intermittent Failures Robot]

1 failures in 3599 pushes (0.0 failures/push) were associated with this bug in the last 7 days.

Repository breakdown:

• mozilla-central: 1

Platform and build breakdown:

• linux1804-64-qr: 1
  • debug: 1

For more details, see:
https://treeherder.mozilla.org/intermittent-failures/bugdetails?bug=602102&startday=2024-01-15&endday=2024-01-21&tree=all

Comment 17

[Jens Stutte [:jstutte]]

Triaging this crash bug for current actionability.

Volume (last 90 days): ~276 crash reports, ~185 crash pings. However, ~67 of those reports come from a single Firefox 130.0.1 installation crashing repeatedly, and the remainder are spread across dozens of completely different call stacks.

Bucket signature confirmed: Examining individual crashes confirms what benjamin noted in comment 3 and nika in comment 14 — this is a generic XPCOM QI dispatch function that groups unrelated crashes. The proto_signature facet shows 25+ distinct call paths, including:

• nsMediaSniffer::QueryInterface via HTTP channel processing
• nsNSSCertificate::QueryInterface via cache entry handling
• MessageChannel::MessageTask::QueryInterface on IPC I/O thread
• Many truncated/corrupted stacks with no useful callers

The largest individual cluster is ~7 crashes — none individually actionable from this bug.

NS_TableDrivenQI (source) is not currently in Socorro's prefix_signature_re.txt. Adding it would cause Socorro to generate more specific signatures (e.g. nsMediaSniffer::QueryInterface) so individual root causes get their own bugs instead of being lumped here.

Recommendation: File a Socorro bug to add NS_TableDrivenQI to the prefix list. Once that lands, this bug will stop accumulating new crashes and can be closed. The topcrash/topcrash-startup keywords should be removed as the volume is an artifact of the bucket effect.