19.02 KB, text/plain; charset=UTF-8
29.00 KB, text/plain; charset=UTF-8
29.58 KB, text/plain; charset=UTF-8
944 bytes, patch
|Details | Diff | Splinter Review|
11.90 KB, text/plain
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
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. /be
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. /be
Assignee: dougt → general
Component: XPCOM → Browser-General
This could be a trace-malloc bug, I suppose. /be
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.
Minusing for 1.4 unless someone decides this is real and not a fluke.
Component: Browser-General → XPCOM
Flags: blocking1.4? → blocking1.4-
Sorry. Didn't mean to; apparently I didn't hit reload before posting a comment (after brendan changed it).
(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 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/autoconf.mk .
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.
MozillaAS v1.4.x is not supported anymore. Can anyone reproduce with SeaMonkey v1.1.9 ?
Version: Other Branch → 1.4 Branch
Mozilla 1.4 is long dead and gone. SeaMonkey 1.1x has been EOLed. Closing bug as OBSOLETE
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
Assignee: general → nobody
Component: General → General
Product: SeaMonkey → Core
QA Contact: scc → general
You need to log in before you can comment on or make changes to this bug.