Re: GTK build crashes under X

2006-12-29 Thread Benjamin Riefenstahl
Hi Stephen, all,


Stephen Berman writes:
 Program received signal SIGSEGV, Segmentation fault.
 0xb74b88fa in strcmp () from /lib/libc.so.6
 (gdb) bt
 #0  0xb74b88fa in strcmp () from /lib/libc.so.6
 #1  0xb79c1b45 in FcObjectToPtr () from /usr/lib/libfontconfig.so.1
 #2  0xb79c5741 in FcPatternAddWithBinding () from /usr/lib/libfontconfig.so.1
 [...]
 #41 0xb7df2c9c in gtk_widget_size_request ()
from /opt/gnome/lib/libgtk-x11-2.0.so.0
 #42 0x080f181c in xg_update_frame_menubar (f=0x8644250)
 at /home/steve/emacs-22.0.90/src/gtkutil.c:2924
 #43 0x0808bb95 in set_frame_menubar (f=0x8644250, first_time=1, deep_p=1)
 at /home/steve/emacs-22.0.90/src/xmenu.c:2098
 #44 0x0808bd90 in initialize_frame_menubar (f=0x8644250)
 at /home/steve/emacs-22.0.90/src/xmenu.c:2495
 #45 0x080d6735 in Fx_create_frame (parms=139409981)
 at /home/steve/emacs-22.0.90/src/xfns.c:3368
 #46 0x08159461 in Ffuncall (nargs=2, args=0xbfe1dfa8)
 at /home/steve/emacs-22.0.90/src/eval.c:2997


I got a crash in the same spot with the latest pretest and I found
this thread in the mail archive.


I analysed it like this:

- The crash occurs because Fontconfig's (libfontconfig.so) data
  structures are corrupted, more specifically this involves a linked
  list in Fontconfig's fcname.c.

- That linked list is built from data that is passed-in through a
  Fontconfig API and used unchecked.

- The caller that registered this particular piece of data is Xft
  (libXft.so), called through the QT library linked in by
  gtk-qt-engine.  gtk-qt-engine seems to be a Gnome theme, probably
  used to coordinate settings of Gnome clients with KDE (my main
  desktop).

- gtk-qt-engine is loaded during Emacs' call to
  gtk_settings_set_string_property() in gtkutil.c:xg_initialize().

- When the crash occurs, gtk-qt-engine is not loaded any more.  It
  seems to get unloaded after the settings have been determined.  Xft
  is loaded (through Pango), but it is in a different place now than
  it used to be before, because Pango has re-loaded it on-demand long
  after it was already unloaded together with gtk-qt-engine.

The root cause seems to be that the Xft shared library is not
unloadable, it doesn't cleanup and unregister the data that it has
passed to fontconfig.


Work-arounds that fix it for me:

- Uninstall gtk-qt-engine. 

- Preload Xft using LD_PRELOAD. 


Possible work-around in Emacs:

- Link to Xft and call XftInit(0) in gtkutil.c:xg_initialize() or even
  before that.


I'm not sure where exactly the problem *should* be fixed.

- Fontconfig could copy the data that comes in.

- Xft could allocate the data on the heap instead of using a static
  structure.

- Xft could prevent unloading of itself. 

- Xft could provide a cleanup routine for QT and/or gtk-qt-engine to
  use.

- gtk-qt-engine could prevent unloading of Xft.  It makes things
  unusually complicated by combining the two toolkits in one process.


benny



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: National Language Support Functions

2006-12-22 Thread Benjamin Riefenstahl
Hi Eli,


Eli Zaretskii writes:
 Could people who have access to MS-Windows please try these two
 programs and report the results?

On W2K, US-English version, but with the general locale, keyboard
layout and other settings set to German:

  I:\Projects\test-nls .\test1
  SYS: 0x407, USR: 0x407

  I:\Projects\test-nls .\test2
  LangID = SYS: 0x407, USR: 0x407
  LCID = SYS: 0x407, USR: 0x407
  GetUserDefaultUILanguage() = 0409
  GetSystemDefaultUILanguage = 0409

On W98, German version, no changes to the German defaults:

  C:\bennytest1
  SYS: 0x407, USR: 0x407

  C:\bennytest2
  LangID = SYS: 0x407, USR: 0x407
  LCID = SYS: 0x407, USR: 0x407
  Win 9x registry language = 0407


benny



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Re: National Language Support Functions

2006-12-22 Thread Benjamin Riefenstahl
Hi Eli,


Benjamin Riefenstahl writes:
 On W2K, US-English version, but with the general locale, keyboard
 layout and other settings set to German:
 
   I:\Projects\test-nls .\test1
   SYS: 0x407, USR: 0x407
 
   I:\Projects\test-nls .\test2
   LangID = SYS: 0x407, USR: 0x407
   LCID = SYS: 0x407, USR: 0x407
   GetUserDefaultUILanguage() = 0409
   GetSystemDefaultUILanguage = 0409

Eli Zaretskii writes:
 And what tutorial would you expect Emacs to present to you? the
 German one or the English one?

The language of my UI, i.e. English.  I use English OS versions
because I prefer to learn and use the original terminology.


benny



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug


Mac: set-language-environment trashes default-file-name-coding-system

2006-11-05 Thread Benjamin Riefenstahl
Hi all,

- Start Emacs as emacs -q. 
- default-file-name-coding-system is set to 'utf-8. 
- M-x set-language-environment RET UTF-8 RET. 
- default-file-name-coding-system is now set to 'iso-latin-1 (!). 

On Mac OS X the encoding of filenames is always UTF-8.

The problem occurs in the implementation of set-language-environment
in mule-cmds.el.  set-language-environment calls
reset-language-environment which sets default-file-name-coding-system
to iso-latin-1 unconditionally.  After that, set-language-environment
calls set-default-coding-systems but that function avoids setting
default-file-name-coding-system specifically on Darwin/Mac OS X.

benny


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug