142841 - M11A Trunk crashes in hashtable lookups [@ PL_HashTableRawLookup]

Status: RESOLVED WORKSFORME

(Core :: XPCOM, defect)

Description

[greer]

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.

Comment 1

[greer]

Attachment: 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

[Wan-Teh Chang]

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.

Comment 3

[Mike Shaver (:shaver emeritus)]

Attachment: 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

[Wan-Teh Chang]

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.)

Comment 5

[Mike Shaver (:shaver emeritus)]

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

[Wan-Teh Chang]

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.)

Comment 7

[greer]

D.Baron, at the suggestion of wtc (comment #2 below) reassigning to you. 
(Nothing personal.) Please reassing if you disagree.

Comment 8

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

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.

Comment 9

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

(The bug on converting the RuleHash tables to pldhash is bug 112318.)

Comment 10

[greer]

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]

Comment 11

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

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.

Comment 12

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

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.

Comment 13

[greer]

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:

Comment 14

[Doug Turner (:dougt)]

greer does this crash still occur?  

Comment 15

[Jan Carpenter]

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.

Comment 16

[Brendan Eich [:brendan]]

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

Comment 17

[Doug Turner (:dougt)]

Looking at the talkback data, I do not see this signature in the top 25 for
trunk builds.

Comment 18

[Jan Carpenter]

It's not showing up in the reports, and there are no recent submissions in the
database.

Comment 19

[Doug Turner (:dougt)]

wfm