Closed Bug 102208 Opened 23 years ago Closed 23 years ago

Cannot launch from Japanese locale (TRUNK only) - [@ libX11.so.6 - GetSystemFontInfo]

Categories

(Core :: Internationalization, defect)

Product:
Core
Component:
Internationalization
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: tracy, Assigned: dbaron)

References

Details

(Keywords: crash, regression, topcrash)

Crash Data

Attachments

(4 files)

proposed fix, diff -u
5.17 KB, patch
Details | Diff | Splinter Review
proposed fix, diff -uw
3.55 KB, patch
Details | Diff | Splinter Review
patch, v2, diff -u
7.39 KB, patch
jag+mozilla
: review+
Details | Diff | Splinter Review
patch, v2, diff -uw
7.77 KB, patch
Details | Diff | Splinter Review 
seen on linux commercial build 2001-09-28-06-trunk

-attempt to launch from Japanese locale
    ~setenv LANG ja
    ~setenv LC_ALL ja

launching the app fails
Keywords: smoketest
This doesn't happen on 2001-09-27-06-trunk comm. build.
./netscape -profilemanager fails to launch too.
since this is only japanese locale, I'm going to have gerv land his license updates.
I think it's a regression - it was works fine on 09-26 trunk build.
Keywords: regression
QA Contact: andreasb → ylong
peterv landed sorting for xslt today which uses nsICollation and locals. The 
landing was a bit bumpy since the REQUIRES landing has affected transformiix in 
a bad way. See bug 102138 and bug 65858
assiging to bstell (i18n-linux issue)
Assignee: yokoyama → bstell
Could this maybe be related to bug 102168, maybe a dup?
my current (about noon pST) build on Redhat 7.1 fails to load with this message:

nsNativeComponentLoader: autoregistering begins.
**************************************************
nsNativeComponentLoader:
SelfRegisterDll(/builds/bstell/4mojo/mozilla/dist/bin/components/libgkcontent.so)
Load FAILED with error:
/builds/bstell/4mojo/mozilla/dist/bin/components/libgkcontent.so: undefined
symbol: 
nsXULAtoms::page
**************************************************
nsNativeComponentLoader: autoregistering succeeded

> launching the app fails

Could we describe the symptoms of the failure?

  core dumps?
  hangs?
  exits silently?
exits silently
I set LANG=ja and LC_ALL=ja and it starts up okay for me
I'll try downloading today's build.
I downloaded 2001-928-08-trunk and it starts in the default locale (C/en_US).
When I set LANG=ja it complains the "ja" locale not supported.
When I set LANG=ja_JP.eucJP it hangs.

not a mozilla smoketest. removing keyword.
Keywords: smoketest
I can get my current build to hang if I set LANG=ja_JP.eucJP
I see that on Tracey's system it exits silently if we set LC_ALL=ja_JP.eucJP.
here is the stack when the browser hangs on my system:

(gdb) bt
#0  0x405cb8a5 in __sigsuspend (set=0x41e718ac) at
../sysdeps/unix/sysv/linux/sigsuspend.c:45
#1  0x402e00d9 in __pthread_wait_for_restart_signal (self=0x41e71c00) at
pthread.c:934
#2  0x402dcc5c in pthread_cond_wait (cond=0x8117a94, mutex=0x8109238) at
restart.h:34
#3  0x402ab24c in PR_WaitCondVar (cvar=0x8117a90, timeout=4294967295) at
ptsynch.c:382
#4  0x401cb9e6 in nsThreadPool::GetRequest (this=0x810d118,
currentThread=0x81c7870) at nsThread.cpp:633
#5  0x401cc7a8 in nsThreadPoolRunnable::Run (this=0x81c7858) at nsThread.cpp:865
#6  0x401ca24d in nsThread::Main (arg=0x81c7870) at nsThread.cpp:105
#7  0x402b270e in _pt_root (arg=0x81c78f0) at ptthread.c:214
#8  0x402ddbfd in pthread_start_thread (arg=0x41e71c00) at manager.c:262
#9  0x402ddcdf in pthread_start_thread_event (arg=0x41e71c00) at manager.c:285

I find it hangs for ja_JP.eucJP on the 2001-27-21-trunk build
I find it is okay for ja_JP.eucJP on the 2001-09-26-08-trunk build
I find it is okay for ja_JP.eucJP on the 2001-09-27-13-trunk build
brian: can you generate stack traces of the other threads as well?
My build from this afternoon works. I have a stock RH7.1 install, and did

  $ LANG=ja LC_ALL=ja ./mozilla

Do I need a special environment to test this? (Note that I got a warning:
``Gdk-WARNING **: locale not supported by C library'').
after backing out the patch for bug 33313 it starts for locale ja_JP.eucJP
and ko_KR_euckr which were both failing before.

assigning to dbaron.
Assignee: bstell → dbaron
waterson: try "ja_JP.eucJP" instead of "ja"

The problem is that |theFont->type| is GDK_FONT_FONTSET rather than
GDK_FONT_FONT.  This means that the cast of GDK_FONT_XFONT to (XFontStruct*) is
invalid.  It is, instead, an XFontSet.  What I'm trying to figure out now is
what an XFontSet is and whether I can do something useful with it.

(FWIW, the existing code made this same broken assumption, it just always used a
GtkStyle that was so simply initialized that it always had the same font.)
And, for the record, the real stack (of, in my case, a hang) is:

#0  0x407caa30 in XGetFontProperty () from /usr/X11R6/lib/libX11.so.6
#1  0x418480b1 in nsSystemFontsGTK::GetSystemFontInfo(_GdkFont*, nsFont*, float)
const (this=0x41873898, iFont=0x81721e8, aFont=0x82c60a0, aPixelsToTwips=14)
    at /builds/trunk/mozilla/gfx/src/gtk/nsDeviceContextGTK.cpp:797
#2  0x41847d12 in nsSystemFontsGTK::nsSystemFontsGTK(float) (this=0x82c60a0, 
    aPixelsToTwips=14)
    at /builds/trunk/mozilla/gfx/src/gtk/nsDeviceContextGTK.cpp:691
#3  0x4184699c in nsDeviceContextGTK::GetSystemAttribute(nsSystemAttrID,
SystemAttrStruct*) const (this=0x82088f0, anID=eSystemAttr_Font_MessageBox, 
    aInfo=0xbfffcf38)
    at /builds/trunk/mozilla/gfx/src/gtk/nsDeviceContextGTK.cpp:341
Attachment #51370 - Attachment description: proposed fix, diff -w → proposed fix, diff -u
sr=hyatt

The other possibility is that I'm better of just bailing if I hit a fontset,
rather than using the first font.  Or maybe there's even something intelligent I
could do.  Any suggestions?  I'm going to check something in tonight whether or
not I hear an answer to allow the builds to run again -- we can always improve
it later.
I'm going to try a better patch (after a discussion with dp) by appending all of
the names and using the size and weight of the first.
Comment on attachment 51380 [details] [diff] [review]
patch, v2, diff -u

>Index: nsDeviceContextGTK.cpp
>===================================================================
>RCS file: /cvsroot/mozilla/gfx/src/gtk/nsDeviceContextGTK.cpp,v
>retrieving revision 1.84
>diff -u -d -r1.84 nsDeviceContextGTK.cpp
>--- nsDeviceContextGTK.cpp	2001/09/27 23:44:40	1.84
>+++ nsDeviceContextGTK.cpp	2001/09/29 02:25:05
>@@ -659,15 +659,20 @@
>   return 0;
> }
> 
>+#define DEFAULT_TWIP_FONT_SIZE 240
>+

<snip/>

>     mMenuFont("sans-serif", NS_FONT_STYLE_NORMAL, NS_FONT_VARIANT_NORMAL,
>-               NS_FONT_WEIGHT_NORMAL, NS_FONT_DECORATION_NONE, 240)
>+               NS_FONT_WEIGHT_NORMAL, NS_FONT_DECORATION_NONE, DEFAULT_TWIP_FONT_SIZE)

wrap this one as well.

r=jag
Attachment #51380 - Flags: review+
Fix checked in 2001-09-28 22:06 PDT.  Further review from someone else familiar
with X font code would be appreciated.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
*** Bug 102168 has been marked as a duplicate of this bug. ***
> What I'm trying to figure out now is
> what an XFontSet is and whether I can do something useful with it.

I don't pretend to be an X programmer, but this is what I understand.

XFontSet (vs XFontStruct) allows you to specify multiple fonts. For some
languages (e.g., Chinese, Japanese and Korean), X11 needs several fonts to
draw all the characters.  There are similar library functions that are used
for XFontSet instead of XFontStruct.

Internationally enabled apps usually use XFontSet instead of XFontStruct.

I found one reference that discusses this:
  http://www.debian.org/doc/manuals/intro-i18n/ch-output.html
   - See 7.2.1 Xlib programming

bstell probably can provide better information on how this really works...

That was my basic understanding.  The solution I chose for mapping an XFontSet
into a CSS font definition was to use the names of all the fonts in the set to
build a comma-separated name list, but to use the size and the weight of the
first font in the set (presumably they would be similar, at least).
*** Bug 102327 has been marked as a duplicate of this bug. ***
Fixed verified on 10-01 linux trunk build.
Status: RESOLVED → VERIFIED
Adding crash, topcrash keywords and [@ libX11.so.6 + 0x1e7f0 -
GetSystemFontInfo] to summary for tracking.  This was a topcrasher on the
MozillaTrunk with builds 20010928XX.
Keywords: crash, topcrash
Summary: Cannot launch from Japanese locale (TRUNK only) → Cannot launch from Japanese locale (TRUNK only) - [@ libX11.so.6 - GetSystemFontInfo]
Crash Signature: [@ libX11.so.6 - GetSystemFontInfo]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: