Closed Bug 71 Opened 26 years ago Closed 26 years ago

assertion failed in mozilla.c

Categories

(MozillaClassic Graveyard :: XFE, defect, P2)

1998-03-31
SGI
IRIX

Tracking

(Not tracked)

VERIFIED WONTFIX

People

(Reporter: sbrostig, Assigned: akkzilla)

Details

Created by Svein Erik Brostigen (sbrostig@no.oracle.com) on Tuesday, April 7, 1998 5:50:41 AM PDT
Additional Details :
When running Mozilla the assertion in line 997 in mozilla.c
fails. The variable "spinning_wildly" is trigging an
assertion failed when spinning_wildly > 12. I have done
some debugging here and found that a value of 30 is too
little. This is not a serious bug though.
Btw, we need an IRIX 6.4 OS version entry here.
Updated by Terry Weissman (terry@netscape.com) on Tuesday, April 7, 1998 8:52:01 AM PDT
Additional Details :
IRIX 6.4 now exists in the database; this bug has been changed to use it.
Component: XFE
Assignee: nobody → {}
Assignee: {} → ramiro
I have no idea whats going on here.  I dont see this bug in either linux or
solaris.

I need a irix volunteer to debug this.

Adding akkana@netscape.com to cc since she uses irix daily and might have some
info.
FWIW, I get the same behavior in Data General DG/UX.  I also tracked it down to
the 'spinning wildly' stuff, but haven't had the chance to investigate exactly
why it happens.  I don't think I'm seeing any user-visible misbehavior because
of it.

Note that there are some comments in this area of mozilla.c that indicate that
some Xt libraries are known to be broken in some way that is probably related to
this, but I'm a little unclear on what exactly the problem is.  DG/UX's X is
based on a pretty old rev-- R4, I think (I'll have to double check).  Could the
same be true of Irix?
I use IRIX 6.3 but haven't seen this recently.  When do you see the assertion --
are there particular pages that are more likely to trigger it?  If you can give
me an idea how to reproduce it, I can try it on 6.3 -- maybe it's a difference
between 6.3 and 6.4?
Assignee: ramiro → akkana
akkana, thanks for replying.  The bug is yours now ;-)

Reassign to akkana.
On DG/UX, I'm seeing this assertion failure all the time, even when Mozilla is
apparently idle.  In fact, I'm seeing it right now, on this very page.

BTW, I checked, and I was wrong, DG/UX is currently at X11R5, not R4.  Well, at
least the X server is, I might have to delve a little deeper and make sure that
the libXt version matches the server version.
If you're seeing it that often, I can only guess that it is indeed a change from
6.3 to 6.4, since I'm not seeing it in 6.3 (I'm using Mozilla on 6.3 to write
this).
Have you checked to see how big spinning_wildly actually gets?  Like, is this
something where maybe just changing it from 12 to 15 might help?  Looks like
whoever put spinning_wildly in in the first place was just guessing the high-end
numbers based on what was observed, and tuning them to go along with nspr or
other variables ...
I stuck some printfs in to see what spinning_wildly was doing when the assertion
failed, and the only values I've seen come out of it are 12 and 13.  So yeah,
bumping the assertion check up to 15 would stop it from failing, though it
leaves me at least with no better understanding of what's actually happening
here.

I think I'll try building a more recent set of X libs (particularly Xt) and
linking against that.  If that gets spinning_wildly down, we can just chalk it
up to a bad Xt library, and then bumping the assertion check up to 15 is fine by
me.
Status: NEW → ASSIGNED
Have you had a chance to try the new Xt library?  Are you still seeing these
asserts?
I have not been able to check, because other problems have rendered Mozilla
totally inoperable on my platform at the moment.  I'm seeing a bus error on
startup in _XtCompileResourceList for the chrome manager widget, according to
Ramiro's interpretation of my stack trace.  Once that's resolved and I'm up
and running again, I'll let you know.
Actually, I still have the old sources that used to work kicking around, I
think, so if this current bus error problem drags out too long, I can work
with those to see what X11R6 does.
I got past the other bus error thing, and tried linking against X11R6.  Not only
is it not an improvement, it's actually worse.  With R6, "spinning_wildly" goes
as high as 18, and the error seems to happen more often.  With the system R5
libraries, it's still not going over 13.  If you want to just increase the
limit, that's ok by me.  I don't know what's going on here, but maybe it doesn't
really matter.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → WONTFIX
Old bug, old codebase. Marking won't fix. Re-open if I am incorrect.
Status: RESOLVED → VERIFIED
setting to an approximate milestone so it can be off of the no TFV list
Target Milestone: --- → M12
You need to log in before you can comment on or make changes to this bug.