M11A Trunk crashes in hashtable lookups [@ PL_HashTableRawLookup]

RESOLVED WORKSFORME

Status

()

Core
XPCOM
RESOLVED WORKSFORME
16 years ago
16 years ago

People

(Reporter: greer, Assigned: dougt)

Tracking

({crash, qawanted, topcrash-})

Trunk
x86
All
crash, qawanted, topcrash-
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(2 attachments)

(Reporter)

Description

16 years ago
The hashtable lookup code is crashing for a lot of the RC1 users.
I haven't been able to reproduce it yet myself. According to the log, this 
section of the code hasn't changed much since it was created. However, it looks 
like bug 92810 relates specifically to this section of the code and further 
tweaks may be necessary. (cc'ing be) Feel free to correct my selection of NSPR 
version.

M1RC1 (PL_HashTableRawLookup):       60
  57 Windows
   3 Linux
2002041717
2002041711

Here is the most common stack.

 Stack trace(Frame) 

         PL_HashTableRawLookup  [../../../lib/ds/plhash.c  line 206] 
         PL_HashTableLookup     [../../../lib/ds/plhash.c  line 389] 
         nsHashtable::Get       
[d:\builds\seamonkey\mozilla\xpcom\ds\nsHashtable.cpp  line 308] 
         RuleHash::EnumerateAllRules
[d:\builds\seamonkey\mozilla\content\html\style\src\nsCSSStyleSheet.cpp  line 
597] 
         _hashValueCompare      
[d:\builds\seamonkey\mozilla\xpcom\ds\nsHashtable.cpp  line 149]  
 
     (5906839)  URL: www.planethalflife.com/cswaypoints
     (5906839)  Comments: just opened the link
     (5822330)  URL: java.sun.com
     (5822330)  Comments: selected "yes" to get and install the java plugin
     (5821031)  URL: www.metafilter.com
     (5818115)  Comments: down loading x-java applet
     (5776003)  Comments: Attempting to used tabbed pages; selecting 'Tabs' then 
'Customize Sidebar' produced this crash.
(Reporter)

Updated

16 years ago
Keywords: crash, qawanted, topcrash
Whiteboard: [grr]
(Reporter)

Comment 1

16 years ago
Created attachment 82664 [details]
Remaining crashes under this signature

Here are the remaining crashes in M1RC1 under this signture. Again, sorted by
uniqu offset and coupled with user comments for that unique stack.

Comment 2

16 years ago
Please reassign to the Product/Component that owns
mozilla\content\html\style\src\nsCSSStyleSheet.cpp.

The problem is most likely that someone is calling
PL_HashTableLookup from a hashtable enumeration
function.  You have to call PL_HashTableLookupConst
instead.  See bug 32184 and bug 89465 for previous
instances of the problem.
Created attachment 82673 [details] [diff] [review]
Add assertion to catch lookup-from-enum before we get to the field.

wtc, what would you say to something like this?  It might help catch these
errors
earlier, and keep them (properly) out of your group's buglist.

(Untested, but it does compile!)

Comment 4

16 years ago
Comment on attachment 82673 [details] [diff] [review]
Add assertion to catch lookup-from-enum before we get to the field.

shaver,

A patch similar to this was proposed by Patrick Beard
in bug 32184 before.  I can't take these patches in NSPR
4.x because they break binary compatibility.  (See my
response to Patrick's proposal in
http://bugzilla.mozilla.org/show_bug.cgi?id=32184#c3.)
I was concerned about binary compatibility as well, which is why I covered them
in DEBUG.  Are there really people who expect to drop a DEBUG NSPR into a DEBUG
app and not have to recompile?  How does the existing HASHMETER affect binary
compatibility?

I'm happy to bracket it with #ifdef BININCOMPAT_ENUM_CHECK and set that for
Mozilla's build, if we have to go that far (or just MOZILLA_CLIENT and DEBUG,
perhaps).

Comment 6

16 years ago
shaver:

There are people who expect to drop a DEBUG NSPR into a DEBUG
or OPTIMIZED app and not have to recompile.

We do not define HASHMETER in the regular DEBUG and OPTIMIZED
NSPR, so HASHMETER does not affect binary compatibility.  (We
only care about the binary compatibility of the regular NSPR
builds.)
(Reporter)

Comment 7

16 years ago
D.Baron, at the suggestion of wtc (comment #2 below) reassigning to you. 
(Nothing personal.) Please reassing if you disagree.
Assignee: wtc → dbaron
Component: NSPR → Style System
Product: NSPR → Browser
We never enumerate any of these tables, so the problem suggested in comment 2 is
not the cause of the crash.

I had a patch to convert this to pldhash, but it didn't work (it crashed when
loading the chrome, although web pages worked fine in viewer), and I didn't get
a chance to figure out why.
(The bug on converting the RuleHash tables to pldhash is bug 112318.)
(Reporter)

Comment 10

16 years ago
cc'ing dougt, dp and scc who have ties to XPCOM. Looking for possible causes of
the crash in:
nsHashtable::Get [d:\builds\seamonkey\mozilla\xpcom\ds\nsHashtable.cpp  line 308]
The vast majority of the crashes in PL_HashTableRawLookup are from a bad
(non-null) |he| pointer on the line:

        if (he->keyHash == keyHash && (*ht->keyCompare)(key, he->key)) {

Most of the stacks on Windows are garbled, but the Linux stack I looked at that
isn't doesn't show access during enumeration.
I'm going to toss this bug back to XPCOM.  None of the stacks show enumeration,
and some of the hashtables in question are never enumerated.  The stacks also
show various hashtables in different parts of the code.  (Some are through
nsHashtable, some aren't.)  I really don't have any ideas as to what's causing
it, though.
Assignee: dbaron → dougt
Component: Style System → XPCOM
QA Contact: wtc → scc
(Reporter)

Comment 13

16 years ago
This one is still happening on the Trunk and branch, but the most recent crash
on the Trunk was almost 10 days ago. -> topcrash-

M11A (PL_HashTableRawLookup):        5
 Unique Users  5
(7531389) - [Windows NT  5.1 build 2600] (Build 2002061104)- 2002-06-20 :
nothing @ all... was out and came in and it had crashed...  URL: 
 
M100 (PL_HashTableRawLookup):       26
 Unique Users  21
(7565518) - [Windows 98  4.10 build 67766446] (Build 2002053015)- 2002-06-21 :
attempting to open adobe pdf  multi reloads on my part. URL: http:\\usrobotics ?
(7624089) - [Windows 98  4.10 build 67766446] (Build 2002053015)- 2002-06-23 :
was opening acrobat URL: 
(7561713) - [Linux 2.4.18-xfs-1.1] (Build 2002052918)- 2002-06-20 : Opening pdf
document in browser. Acrobat reader was starting. URL: 
 
Trunk (PL_HashTableRawLookup):        3
 Unique Users  3
(7467344) - [Windows 98  4.10 build 67766446] (Build 2002061707)- 2002-06-18 :
Crashed while trying to print URL:
Keywords: topcrash → topcrash-
Whiteboard: [grr]
(Reporter)

Updated

16 years ago
Summary: M1RC1 Trunk crashes in hashtable lookups [@ PL_HashTableRawLookup] → M11A Trunk crashes in hashtable lookups [@ PL_HashTableRawLookup]
(Assignee)

Comment 14

16 years ago
greer does this crash still occur?  

Comment 15

16 years ago
I don't see this stack happening in todays Talkback reports.  In a quicksearch
it was showing up on builds as recent as 20021126, but nothing after that.
greer, janc: dbaron fixed bug 112318 way back at the end of May.  alecf changed
nsHashtable to use PLDHashTable on or around 11/15.  Maybe something else
changed to stop this crash.

In the recent crashes (just from the last half of November), what was the common
stack backtrace?  It can't have gone through the code dbaron changed at the end
of May, and it can't have involved nsHashtable instances after alecf's change.

/be
(Assignee)

Comment 17

16 years ago
Looking at the talkback data, I do not see this signature in the top 25 for
trunk builds.
Severity: critical → normal

Comment 18

16 years ago
It's not showing up in the reports, and there are no recent submissions in the
database.
(Assignee)

Comment 19

16 years ago
wfm
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
Crash Signature: [@ PL_HashTableRawLookup]
You need to log in before you can comment on or make changes to this bug.