209956 - Assertion failure on the 1.4 branch in plhash.c

Status: RESOLVED INCOMPLETE

(Core :: General, defect)

Description

[Randell Jesup [:jesup] (needinfo me)]

This assertion and exit happened in the 1.4 tinderbox (see above log).  It
appears to be a race condition or something that doesn't happen every time; the
only checkin during that period was a mac build checkin that can't affect Linux.

WARNING: empty damage rect: update caller to avoid fcn call overhead, file
/builds/tinderbox/Linux_2.2.24-6.2.3_Depend/mozilla/layout/html/base/src/nsFrame.cpp,
line 2694
  Assertion failure: *hep == 0, at
/builds/tinderbox/Linux_2.2.24-6.2.3_Depend/mozilla/nsprpub/lib/ds/plhash.c:275
----------- End Output from  bloat test --------- 
Error: mozilla-bin: exited with status 6

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

I checked the previous log before the orange; there was no assertion in that
run, so that points at the assertion leading to the crash.

Comment 2

[Brendan Eich [:brendan]]

Note plhash, not pldhash.

Not sure why seth was cc'd.

We need a stack backtrace.

/be

Comment 3

[Brendan Eich [:brendan]]

Not an XPCOM bug, probably not a plhash.c bug, more likely a layout bug.  But we
need a stack, and until we get one, this goes to b-g.

/be

Comment 4

[Brendan Eich [:brendan]]

This could be a trace-malloc bug, I suppose.

/be

Comment 5

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

I've seen this happen occasionally on other tinderboxes in the past.  I think
it's some sort of a tools bug on the system.  It's currently Red Hat 6.2 with
upgraded binutils and gcc 3.2.3.

Comment 6

[Randell Jesup [:jesup] (needinfo me)]

Minusing for 1.4 unless someone decides this is real and not a fluke.

Comment 7

[Randell Jesup [:jesup] (needinfo me)]

Sorry.  Didn't mean to; apparently I didn't hit reload before posting a comment
(after brendan changed it).

Comment 8

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

Attachment: stack from Linux h-10-169-105-194 Depend on 06/20 06:09

Comment 9

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

(I think I actually have seen this occasionally when running with trace-malloc,
now that I think of it.  I'm not sure, though.)

Comment 10

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

So if I understand what's going on here correctly, the assertion is asserting
that there aren't duplicate entries in the hashtable.  Since all users of the
hashtable use PL_HashTableAdd (not PL_HashTableRawAdd), I don't see how the
table could end up with duplicate entries unless they're being modified after
they're added.

Comment 11

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

Attachment: log and stack from Linux h-10-169-105-194 Depend on 06/20 11:16

Comment 12

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

Attachment: log and stack from Linux h-10-169-105-194 Depend on 06/20 18:36

Comment 13

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

Attachment: logging patch

The patch I used for logging the stacks (which required turning off security,
which I did by hacking MOZ_PSM in $(MOZ_OBJDIR)/config/autoconf.mk .

Comment 14

[Jarmo]

Attachment: Crash stack using gdb bt

Comment 15

[Jarmo]

One more crash (PR_Assert) from plhash.c:275  
Triggered by clicking back button, earlier build (week, or more old) did not crash.  
Started to crash yesterday (after CVS update). *I* do not think its plhash.c that is  
the evil one, it seems that something is just using plhash.c in a way it should not.  
Linux stack attached.  

Comment 16

[Serge Gautherie (:sgautherie)]

MozillaAS v1.4.x is not supported anymore.

Can anyone reproduce with SeaMonkey v1.1.9 ?

Comment 17

[Philip Chee]

Mozilla 1.4 is long dead and gone.
SeaMonkey 1.1x has been EOLed.
Closing bug as OBSOLETE