Assertion failure on the 1.4 branch in plhash.c




15 years ago
7 years ago


(Reporter: jesup, Unassigned)


({assertion, crash})

1.4 Branch
assertion, crash
Bug Flags:
blocking1.4 -

Firefox Tracking Flags

(Not tracked)




(5 attachments)



15 years ago
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
line 2694
  Assertion failure: *hep == 0, at
----------- End Output from  bloat test --------- 
Error: mozilla-bin: exited with status 6


15 years ago
Flags: blocking1.4?

Comment 1

15 years ago
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.
Note plhash, not pldhash.

Not sure why seth was cc'd.

We need a stack backtrace.

Summary: Assertion failure on the 1.4 branch in pldhash.c → Assertion failure on the 1.4 branch in plhash.c
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.

Assignee: dougt → general
Component: XPCOM → Browser-General
This could be a trace-malloc bug, I suppose.

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

15 years ago
Minusing for 1.4 unless someone decides this is real and not a fluke.
Component: Browser-General → XPCOM
Flags: blocking1.4? → blocking1.4-


15 years ago
Component: XPCOM → Browser-General

Comment 7

15 years ago
Sorry.  Didn't mean to; apparently I didn't hit reload before posting a comment
(after brendan changed it).
Created attachment 126131 [details]
stack from Linux h-10-169-105-194 Depend on 06/20 06:09
(I think I actually have seen this occasionally when running with trace-malloc,
now that I think of it.  I'm not sure, though.)
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.
Created attachment 126142 [details]
log and stack from Linux h-10-169-105-194 Depend on 06/20 11:16
Created attachment 126177 [details]
log and stack from Linux h-10-169-105-194 Depend on 06/20 18:36
Created attachment 126178 [details] [diff] [review]
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/ .

Comment 14

14 years ago
Created attachment 136491 [details]
Crash stack using gdb bt

Comment 15

14 years ago
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.  
Product: Browser → Seamonkey
MozillaAS v1.4.x is not supported anymore.

Can anyone reproduce with SeaMonkey v1.1.9 ?
Keywords: assertion
Version: Other Branch → 1.4 Branch

Comment 17

7 years ago
Mozilla 1.4 is long dead and gone.
SeaMonkey 1.1x has been EOLed.
Closing bug as OBSOLETE
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
Assignee: general → nobody
Component: General → General
Product: SeaMonkey → Core
QA Contact: scc → general


7 years ago
You need to log in before you can comment on or make changes to this bug.