Closed Bug 71 Opened 27 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.