Intermittent crash in 508168-1.html [@ RuleHash_TagTable_ClearEntry]

RESOLVED INVALID

Status

()

--
critical
RESOLVED INVALID
7 years ago
6 years ago

People

(Reporter: emorley, Unassigned)

Tracking

({crash, intermittent-failure})

15 Branch
x86
Windows 7
crash, intermittent-failure
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [badslave?][talos-r3-w7-038], crash signature)

Rev3 WINNT 6.1 mozilla-aurora pgo test crashtest on 2012-06-23 08:33:33 PDT for push d21ac6d7b1e7

slave: talos-r3-w7-038

https://tbpl.mozilla.org/php/getParsedLog.php?id=12935846&tree=Mozilla-Aurora

{
REFTEST TEST-START | file:///c:/talos-slave/test/build/reftest/tests/layout/generic/crashtests/508168-1.html | 1280 / 2066 (61%)
TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/generic/crashtests/508168-1.html | Exited with code -1073741819 during test run
INFO | automation.py | Application ran for: 0:05:13.347000
INFO | automation.py | Reading PID log: c:\users\cltbld\appdata\local\temp\tmpyjyrijpidlog
Downloading symbols from: http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-aurora-win32/1340456323/firefox-15.0a2.en-US.win32.crashreporter-symbols.zip
PROCESS-CRASH | file:///c:/talos-slave/test/build/reftest/tests/layout/generic/crashtests/508168-1.html | application crashed (minidump found)
Crash dump filename: c:\users\cltbld\appdata\local\temp\tmpr-i81l\minidumps\df573bb3-b3c1-4462-8f8f-c7b025a60ac5.dmp
Operating system: Windows NT
                  6.1.7600 
CPU: x86
     GenuineIntel family 6 model 23 stepping 10
     2 CPUs

Crash reason:  EXCEPTION_ACCESS_VIOLATION_READ
Crash address: 0x0

Thread 0 (crashed)
 0  xul.dll!RuleHash_TagTable_ClearEntry [nsCSSRuleProcessor.cpp:d21ac6d7b1e7 : 306 + 0x10]
    eip = 0x692a8f32   esp = 0x0020c904   ebp = 0x0072ef74   ebx = 0x00000030
    esi = 0x0c20de00   edi = 0x0c20f000   eax = 0x00000000   ecx = 0x0c20de2c
    edx = 0x00000000   efl = 0x00210246
    Found by: given as instruction pointer in context
 1  xul.dll!PL_DHashTableFinish [pldhash.cpp:d21ac6d7b1e7 : 360 + 0x9]
    eip = 0x692659ff   esp = 0x0020c914   ebp = 0x0072ef74
    Found by: stack scanning
 2  xul.dll!RuleHash::~RuleHash() [nsCSSRuleProcessor.cpp:d21ac6d7b1e7 : 584 + 0x5]
    eip = 0x6920bbdd   esp = 0x0020c930   ebp = 0x0072ef74
    Found by: stack scanning
 3  xul.dll!RuleCascadeData::~RuleCascadeData() [nsCSSRuleProcessor.cpp:d21ac6d7b1e7 : 959 + 0x12d]
    eip = 0x69217da3   esp = 0x0020c940   ebp = 0x0072ef74
    Found by: stack scanning
 4  xul.dll!nsCSSRuleProcessor::~nsCSSRuleProcessor() [nsCSSRuleProcessor.cpp:d21ac6d7b1e7 : 1068 + 0x26]
    eip = 0x6930962c   esp = 0x0020c95c   ebp = 0x0072ef74
    Found by: stack scanning
 5  xul.dll!nsHttpTransaction::Close(unsigned int) [nsHttpTransaction.cpp:d21ac6d7b1e7 : 740 + 0x15]
    eip = 0x691bb4b1   esp = 0x0020c96c   ebp = 0x0072ef74
    Found by: stack scanning
 6  xul.dll!nsCSSRuleProcessor::`scalar deleting destructor'(unsigned int) + 0x7
    eip = 0x691b4083   esp = 0x0020c97c   ebp = 0x0072ef74
    Found by: stack scanning
 7  xul.dll!nsCSSRuleProcessor::Release() [nsCSSRuleProcessor.cpp:d21ac6d7b1e7 : 1071 + 0x18]
    eip = 0x691b4076   esp = 0x0020c984   ebp = 0x0072ef74
    Found by: stack scanning
 8  xul.dll!nsCOMPtr<nsISupports>::~nsCOMPtr<nsISupports>() + 0xd
    eip = 0x6928964e   esp = 0x0020c98c   ebp = 0x0072ef74
}
Version: Trunk → 15 Branch
That's showing a null-deref crash on the "entry->~RuleHashTagTableEntry();" line of:

static void
RuleHash_TagTable_ClearEntry(PLDHashTable *table, PLDHashEntryHdr *hdr)
{
  RuleHashTagTableEntry* entry = static_cast<RuleHashTagTableEntry*>(hdr);
  entry->~RuleHashTagTableEntry();
}

so it looks like the pldhash code is passing in null to the clearEntry callback?  That seems incredibly broken if so.
Component: Style System (CSS) → XPCOM
QA Contact: style-system → xpcom
Depends on: 768489
Whiteboard: [orange] → [orange][badslave?][talos-r3-w7-038]
This bug was observed only on one or more of the six machines listed in
bug 787281 comment 11, which seem likely to have bad memory, disk, or
other hardware problem, based on the rate of failures on those machines
and the types of failures observed.

Therefore I'm marking this bug invalid, though it should be reopened if
it occurs on other (more reliable) hardware.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INVALID
Keywords: intermittent-failure
Whiteboard: [orange][badslave?][talos-r3-w7-038] → [badslave?][talos-r3-w7-038]
You need to log in before you can comment on or make changes to this bug.