Closed Bug 59219 Opened 24 years ago Closed 24 years ago

Xsgi crashes when using "decrease font" (ctrl+-)

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Platform:
SGI
IRIX
Type:
defect

Tracking

()

Status:
VERIFIED WORKSFORME

People

(Reporter: matt, Assigned: vishy)

References

Details

(Keywords: crash) 

I grabbed the IRIX 6.5 nightly (nov 5 2000) and unpacked it.  This is the first
irix build that has ever worked for me (i built my gtk with MIPSpro, so previous
irix builds of mozilla couldn't link to it - they seemed to expect gtk and
friends to be built with gcc).  

Basically, once mozilla is up and running and i've played around with it a bit
(gone to a few different sites), i tried to shrink the font size (just to see if
it works).  It crashes Xsgi (arguably this is an Xsgi bug and is perhaps already
fixed by SGI - if so this is an easy bug for you to fix :)

Nov  5 20:54:44 3D:becker Xsgi0[751]: 
Nov  5 20:54:44 2D:becker Xsgi0[751]: Fatal server error:
Nov  5 20:54:44 2D:becker Xsgi0[751]: Beziers this big not yet supported
Nov  5 20:54:44 3B:becker Xsession: bmajik: fatal IO error 131 (Connection reset
by peer)
Nov  5 20:54:45 3B:becker xdm[744]: Server for display :0 terminated
unexpectedly: 1

This _is_ reproducible for me.  The steps are

1. Start mozilla.
2. Make sure some webpage is loaded (may be optional)
3. hit Ctrl+- (to shrink font)
4. Watch the monitor freak out for a while as the xserver is restarted :)

handy info:
becker:~ 9 > uname -a; uname -R
IRIX becker 6.5 07151432 IP22
6.5 6.5.5m

this is an I^2 R4.4k@200mhz SC1, hi-impact with 1 tram.
Reporter, please try and put your mozilla instance into a shell that survives 
eg (screen), so that you can reconnect after your server dies.  If mozilla in 
fact cores, please give us a stack trace.

Also, in older systems we used a different set of keys to increase/decrease 
fonts. Could you please try using your mouse to activate the menu option. We 
can also use diff to roll back to the other key binding to see if that causes 
it.

attn jag :-(
Assignee: asa → don
Component: Browser-General → XP Apps
QA Contact: doronr → sairuh
akkana, time to brush the dust off of your O2 ;). d'you see this? o'course, you
might still be running irix 6.3, if that'd make any difference...
Component: XP Apps → Keyboard Navigation
Keywords: crash, qawanted
Matt, does this happen at the first ctrl -?

What happens when you set the size through the text size menu?
I can confirm this bug using a MIPSpro build of a slightly
patched M18 source.  Fonts seem to increase OK with CTRL++
and via the menu, but going less than 100% seems to be the
problem.  So it doesn't seem to be that changing font size
itself is a problem.  Maybe there is a bug in Mozilla when
is specifies the new smaller size? but I agree that it
should not crash the X server.

This is an existing SGI Bugworks bug # 632838 -
"X server crashes when Beziers are too big", and it is
still open.  I'll add a note to it to mention that it
is occurring in Mozilla.
reassigning don's open keyboard nav bugs to vishy.
Assignee: don → vishy
So this isn't really a keyboard issue... Anyone know a better component?

Also, the code works just fine on Windows / linux, so it must be a problem with
MIPS specific code... All I just do is feed a double which sets a magnification
factor, 1.0 being 100%... So for numbers smaller than 1.0 something's going
wrong somewhere in the (font?) back-end...
style system, perhaps?
My guess is that it's specific to the gfx font handling code, which is, what,
Compositor?
I think I've found the problem.  I remembered we identified a problem
with floating point parameter passing in xptcall, but other than the
test program failing it never seemed to show up as a problem anywhere.

There is an existing bug 10061 which has a fair bit of stuff in it, but
my latest add "Additional Comments From Robert Low 2000-09-20 19:41"
is the fix that is needed.  It has diffs for floating point stuff in
xpcom/reflect/xptcall/src/md/unix/xptcinvoke_irix.cpp.

If someone else could apply these changes and try it out to confirm
the fix that would be good.  You'll need to do a make in that directory
to remake libxptcmd.a, and then up in xpcom/build to get it into
libxpcom.so.

Although without this change it didn't always crash, the font scaling
never seemed quite right, and sometimes it just showed something
about the same size so I thought it was just using a default fallback.
With the fix it works perfectly, so I'm pretty confident.
Marking NEW since it contains a patch so someone will look at it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: patch
I have a review of a fix going in bug 10061 which appears to
fix this problem.  It's been reviewed, but finalization and
code check-in might have stalled if you'd like to chase it up.
10061 has been fixed, can someone test this?
Depends on: 10061
hrm, i cannot test this --was trying to use mozilla verif bits [2001.01.11.21]
on my O2 which is running Irix 6.3. it won't launch, so methinks i gotta upgrade
to Irix 6.5, which might be in a long while...

anyone else?
I've tried one of the latest nightly binaries and font increase and
decrease now works fine, and doesn't crash the Xserver.

On an unrelated issue, but needed to test this fix,...
There now seems to be a problem with nightly binaries regarding DSO
searchpath for freeware libs like GTK, so I had to set LD_LIBRARY_PATH
myself (setenv LD_LIBRARYN32_PATH .:components:/usr/freeware/lib32)
to get mozilla to run.  I raised a bug 67912 about this.
marking wfm, per robert's comment above.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Once someone can verify this, the final Resolution should be FIXED,
as it was a real bug.  The fix was done via bug 10061.  thanks Rob.
*** Bug 69383 has been marked as a duplicate of this bug. ***
mass verification of WorksForMe bugs: to find all bugspam pertaining to this,
set your search string to "IfItWorksForSlappyTheSquirrelThenItWFM".

if you think this particular bug is *still* an open issue, please make sure of
the following before reopening:

a. that it's still a problem with ***recent trunk builds*** on the all
appropriate platform[s]

b. provide clear steps to reproduce (unless a good test case is already in the
bug report), making sure it pertains to the original problem (avoid morphing as
much as possible :)
Status: RESOLVED → VERIFIED
Keywords: qawanted
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.