Debian Bug report logs - #374640
gedit: freeze when XIM is used to input Japanese text

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: "Hongzheng Wang" <wanghz@gmail.com>

To: submit@bugs.debian.org

Subject: scim: shift key behaves abnormally with XIM

Date: Tue, 20 Jun 2006 19:55:22 +0800

Subject: scim: shift key behaves abnormally with xim
Package: scim
Version: 1.4.4-4
Severity: normal

*** Please type your report below this line ***
Hi,
Due to the C++ ABI transition problem, scim suggests the users use XIM
rather than SCIM.  This is reasonable since XIM support has been
improved in scim.  But the recent upgrade of scim packages contain
some bugs which make shift key behave abnormally when GTK_IM_MODULE
set to xim other than scim.

Let's take scim-pinyin as an example.  When we input some character by
pressing shift key simultaneouslly, say, a colon, scim should
distinguish this usage of shift key from the chinese/english switch by
pressing shift key lonely.  And in fact, scim had the ability in the
past.  But after the last upgrade of scim, scim always consider
pressing shift key as a signal to switch between english and chinese
status of input if GTK_IM_MODULE is set to xim.  This problem,
however, does not exit if GTK_IM_MODULE is set to scim.



-- Package-specific info:
Related packages:
ii  libscim8c2a    1.4.4-4        library for SCIM platform
ii  scim           1.4.4-4        smart common input method platform
ii  scim-gtk2-immo 1.4.4-4        GTK+2 input method module with SCIM as backe
ii  scim-modules-s 1.4.4-4        socket modules for SCIM platform
ii  scim-pinyin    0.5.0-2        smart pinyin IM engine for SCIM platform

Related environment variables:
$XMODIFIERS=@im=SCIM
$GTK_IM_MODULE=xim

Installed SCIM components:
/usr/lib/scim-1.0:
1.4.0
scim-helper-launcher
scim-helper-manager
scim-launcher
scim-panel-gtk

/usr/lib/scim-1.0/1.4.0:
Config
Filter
FrontEnd
Helper
IMEngine
SetupUI

/usr/lib/scim-1.0/1.4.0/Config:
simple.so
socket.so

/usr/lib/scim-1.0/1.4.0/Filter:
sctc.so

/usr/lib/scim-1.0/1.4.0/FrontEnd:
socket.so
x11.so

/usr/lib/scim-1.0/1.4.0/Helper:
setup.so

/usr/lib/scim-1.0/1.4.0/IMEngine:
pinyin.so
rawcode.so
socket.so

/usr/lib/scim-1.0/1.4.0/SetupUI:
aaa-frontend-setup.so
aaa-imengine-setup.so
panel-gtk-setup.so
pinyin-imengine-setup.so

-- System Information:
Debian Release: testing/unstable
 APT prefers unstable
 APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-2-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages scim depends on:
ii  libatk1.0-0                 1.11.4-2     The ATK accessibility toolkit
ii  libc6                       2.3.6-15     GNU C Library: Shared libraries
ii  libcairo2                   1.0.4-2      The Cairo 2D vector graphics libra
ii  libfontconfig1              2.3.2-7      generic font configuration library
ii  libfreetype6                2.2.1-2      FreeType 2 font engine, shared lib
ii  libgcc1                     1:4.1.1-5    GCC support library
ii  libglib2.0-0                2.10.3-1     The GLib library of C routines
ii  libgtk2.0-0                 2.8.18-1     The GTK+ graphical user interface
ii  libpango1.0-0               1.12.3-1     Layout and rendering of internatio
ii  libpng12-0                  1.2.8rel-5.1 PNG library - runtime
ii  libscim8c2a                 1.4.4-4      library for SCIM platform
ii  libstdc++6                  4.1.1-5      The GNU Standard C++ Library v3
ii  libx11-6                    2:1.0.0-6    X11 client-side library
ii  libxcursor1                 1.1.5.2-5    X cursor management library
ii  libxext6                    1:1.0.0-4    X11 miscellaneous extension librar
ii  libxfixes3                  1:3.0.1.2-4  X11 miscellaneous 'fixes' extensio
ii  libxi6                      1:1.0.0-5    X11 Input extension library
ii  libxinerama1                1:1.0.1-4    X11 Xinerama extension library
ii  libxrandr2                  2:1.1.0.2-4  X11 RandR extension library
ii  libxrender1                 1:0.9.0.2-4  X Rendering Extension client libra
ii  zlib1g                      1:1.2.3-11   compression library - runtime

Versions of packages scim recommends:
ii  im-switch                     1.11       Input method switch framework
ii  scim-gtk2-immodule            1.4.4-4    GTK+2 input method module with SCI

-- no debconf information


-- 
Hongzheng Wang

Message #10 received at 374640@bugs.debian.org (full text, mbox, reply):

From: "Hongzheng Wang" <wanghz@gmail.com>

To: 374640@bugs.debian.org

Subject: Only occurring in Gedit

Date: Sat, 18 Nov 2006 16:31:25 +0800

[Message part 1 (text/plain, inline)]

Hi,

It seems that this bug occurs only in gedit.
I tested many other applications, including gnome-terminal, nautilus,
firefox, only gedit encounters this problem.

-- 
Hongzheng Wang

[Message part 2 (text/html, inline)]

Message #15 received at 374640@bugs.debian.org (full text, mbox, reply):

From: Osamu Aoki <osamu@debian.org>

To: 374640@bugs.debian.org

Cc: 374640-submitter@bugs.debian.org, kmuto@debian.org

Subject: gedit: freeze when XIM is used to input Japanese

Date: Sun, 19 Nov 2006 12:06:36 +0900

retitle 374640 gedit: freeze when XIM is used to input Japanese text
reassign 374640 gedit
severity 374640 important
found 374640 2.14.4-2
thanks

Original bug report: http://bugs.debian.org/374640

This freeze problem happens with not only SCIM package as originally
reported but also when using UIM package to input Japanese.  

Kenshi Muto(a Japanese DD) reported to me over Japanese mail that this
happens with UIM and I confirmed it.  Under UIM, this problem does not
happen with other Gnome applications, firefox, gnome-terminal, OOo,
GNOME search tool, too.

Considering this to be rather basic file, it requires attention to be
fixed.

Current work around is to use uim or scim as immodule right after gedit
opens by switching input method using right click text imput area.

Thanks.

Osamu
-- 
~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ +++++
        Osamu Aoki <osamu@debian.org>  Yokohama Japan, GPG-key: A8061F32
 .''`.  Debian Reference: post-installation user's guide for non-developers
 : :' : http://qref.sf.net and http://people.debian.org/~osamu
 `. `'  "Our Priorities are Our Users and Free Software" --- Social Contract

Message #31 received at 374640@bugs.debian.org (full text, mbox, reply):

From: Loïc Minier <lool@dooz.org>

To: Osamu Aoki <osamu@debian.org>

Cc: 374640@bugs.debian.org, 374640-submitter@bugs.debian.org, kmuto@debian.org

Subject: Re: gedit: freeze when XIM is used to input Japanese

Date: Sun, 19 Nov 2006 10:50:57 +0100

[Message part 1 (text/plain, inline)]

        Hi,

On Sun, Nov 19, 2006, Osamu Aoki wrote:
> Original bug report: http://bugs.debian.org/374640
> This freeze problem happens with not only SCIM package as originally
> reported but also when using UIM package to input Japanese.  

 The reporter said this was working with SCIM but not working with XIM
 using SCIM (IIUC).

> Kenshi Muto(a Japanese DD) reported to me over Japanese mail that this
> happens with UIM and I confirmed it.  Under UIM, this problem does not
> happen with other Gnome applications, firefox, gnome-terminal, OOo,
> GNOME search tool, too.

 Is this with UIM under XIM as well?  Or with GTK_IM_MODULE=uim?

 I think all the applications you mention were using a GtkEntry, I've
 attached a Python script creating a GtkTextView, could you try
 reproducing the freeze with the script?

> Current work around is to use uim or scim as immodule right after gedit
> opens by switching input method using right click text imput area.

 This sounds like it breaks when GTK_IM_MODULE=xim and you use SCIM as
 XIM as well.

   Bye,
-- 
Loïc Minier <lool@dooz.org>
        10 SIN
        20 GO TO ROBOT HELL             -- Temple of Robotology

[gtktextview.py (text/x-python, attachment)]

Message #39 received at 374640@bugs.debian.org (full text, mbox, reply):

From: Osamu Aoki <osamu@debian.org>

To: Loïc Minier <lool@dooz.org>

Cc: 374640@bugs.debian.org, 374640-submitter@bugs.debian.org, kmuto@debian.org

Subject: Re: gedit: freeze when XIM is used to input Japanese

Date: Sun, 19 Nov 2006 20:55:39 +0900

On Sun, Nov 19, 2006 at 10:50:57AM +0100, Loïc Minier wrote:
>         Hi,
> 
> On Sun, Nov 19, 2006, Osamu Aoki wrote:
> > Original bug report: http://bugs.debian.org/374640
> > This freeze problem happens with not only SCIM package as originally
> > reported but also when using UIM package to input Japanese.  
> 
>  The reporter said this was working with SCIM but not working with XIM
>  using SCIM (IIUC).

SCIM input method can communicate via several path with application.
SCIM used with immodule (GTK_IM_MODULE=scim) works.  SCIM communicating
through XIM mechanism (GTK_IM_MODULE=xim, XMODIFIERS=@im=SCIM) does not
work.

> > Kenshi Muto(a Japanese DD) reported to me over Japanese mail that this
> > happens with UIM and I confirmed it.  Under UIM, this problem does not
> > happen with other Gnome applications, firefox, gnome-terminal, OOo,
> > GNOME search tool, too.
> 
>  Is this with UIM under XIM as well?  Or with GTK_IM_MODULE=uim?

This is UIM via XIM.  THis is not Qt issue.

>  I think all the applications you mention were using a GtkEntry, I've
>  attached a Python script creating a GtkTextView, could you try
>  reproducing the freeze with the script?

Just to be sure.  gedit is the only broken program.  Everything else works
fine.  Does gedit use GtkEntry too?

> > Current work around is to use uim or scim as immodule right after gedit
> > opens by switching input method using right click text imput area.
> 
>  This sounds like it breaks when GTK_IM_MODULE=xim and you use SCIM as
>  XIM as well.

Yes.

> #!/usr/bin/python
> 
> import pygtk
> 
> pygtk.require("2.0")
> import gtk
> textview = gtk.TextView()
> window = gtk.Window(gtk.WINDOW_TOPLEVEL)
> window.add(textview)
> window.resize(400, 600)
> window.show_all()
> gtk.main()

under GTK_IM_MODULE=xim, XMODIFIERS=@im=uim, above program works fine just
like any other aplications while gedit still freezes.

Osamu

Message #47 received at 374640@bugs.debian.org (full text, mbox, reply):

From: Loïc Minier <lool@dooz.org>

To: Osamu Aoki <osamu@debian.org>

Cc: 374640@bugs.debian.org, 374640-submitter@bugs.debian.org, kmuto@debian.org

Subject: Re: gedit: freeze when XIM is used to input Japanese

Date: Sun, 19 Nov 2006 13:16:12 +0100

[Message part 1 (text/plain, inline)]

On Sun, Nov 19, 2006, Osamu Aoki wrote:
> under GTK_IM_MODULE=xim, XMODIFIERS=@im=uim, above program works fine just
> like any other aplications while gedit still freezes.

 Please try disabling all Gedit plugins, does it help?

 Could you please try the attached python script which uses a
 GtkSourceView widget instead of a GtkTextView one.

-- 
Loïc Minier <lool@dooz.org>
        10 SIN
        20 GO TO ROBOT HELL             -- Temple of Robotology

[gtksourceview.py (text/x-python, attachment)]

Message #55 received at 374640@bugs.debian.org (full text, mbox, reply):

From: Osamu Aoki <osamu@debian.org>

To: Loïc Minier <lool@dooz.org>

Cc: 374640@bugs.debian.org, 374640-submitter@bugs.debian.org, kmuto@debian.org

Subject: Re: gedit: freeze when XIM is used to input Japanese

Date: Sun, 19 Nov 2006 21:26:17 +0900

On Sun, Nov 19, 2006 at 01:16:12PM +0100, Loïc Minier wrote:
> On Sun, Nov 19, 2006, Osamu Aoki wrote:
> > under GTK_IM_MODULE=xim, XMODIFIERS=@im=uim, above program works fine just
> > like any other aplications while gedit still freezes.
> 
>  Please try disabling all Gedit plugins, does it help?

No gedit still freezes.  Pressing X on window eventually get me close
window.

>  Could you please try the attached python script which uses a
>  GtkSourceView widget instead of a GtkTextView one.

Nnice view of source.  I can input Japanese nicely without problem.

Message #63 received at 374640@bugs.debian.org (full text, mbox, reply):

From: Loïc Minier <lool@dooz.org>

To: Osamu Aoki <osamu@debian.org>

Cc: 374640@bugs.debian.org, 374640-submitter@bugs.debian.org, kmuto@debian.org

Subject: Re: gedit: freeze when XIM is used to input Japanese

Date: Sun, 19 Nov 2006 13:55:57 +0100

        Hi,

On Sun, Nov 19, 2006, Osamu Aoki wrote:
> No gedit still freezes.  Pressing X on window eventually get me close
> window.

 Ok, then it seems to really be gedit specific, thanks for the tests.

 Can you please rebuild gedit with debugging symbols and get a backtrace
 of all threads during a freeze?  If you're not familiar with gdb,
 <http://wiki.debian.org/HowToGetABacktrace> has the details.

 I hope this will help.  I suspect it could be a gdk threads issue with
 SCIM and Gedit relying on Gdk threads at the same time.

   Thanks,
-- 
Loïc Minier <lool@dooz.org>
        10 SIN
        20 GO TO ROBOT HELL             -- Temple of Robotology

Message #71 received at 374640@bugs.debian.org (full text, mbox, reply):

From: Osamu Aoki <osamu@debian.org>

To: Loïc Minier <lool@dooz.org>

Cc: 374640@bugs.debian.org, 374640-submitter@bugs.debian.org, kmuto@debian.org

Subject: Re: gedit: freeze when XIM is used to input Japanese

Date: Sun, 19 Nov 2006 22:26:40 +0900

On Sun, Nov 19, 2006 at 01:55:57PM +0100, Loïc Minier wrote:
>         Hi,
> 
> On Sun, Nov 19, 2006, Osamu Aoki wrote:
> > No gedit still freezes.  Pressing X on window eventually get me close
> > window.
> 
>  Ok, then it seems to really be gedit specific, thanks for the tests.
> 
>  Can you please rebuild gedit with debugging symbols and get a backtrace
>  of all threads during a freeze?  If you're not familiar with gdb,
>  <http://wiki.debian.org/HowToGetABacktrace> has the details.

Done but

"If you're lucky, a crash will occur and you'll be dropped back to the
gdb prompt. At that point, you can run:"

Well, it just freezes screen without giving me prompt.

>  I hope this will help.  I suspect it could be a gdk threads issue with
>  SCIM and Gedit relying on Gdk threads at the same time.

Maybe I need break point or so but I am not so familiar with gdb

I will ask Japanese list for help :-)

Osamu

Message #79 received at 374640@bugs.debian.org (full text, mbox, reply):

From: Osamu Aoki <osamu@debian.org>

To: kmuto@debian.org, Ming Hua <minghua@rice.edu>, omote@debian.org, ikuya@oooug.jp, yooseong@debian.org, caleb@calno.com, ygh@debian.org, foka@debian.org, cwryu@debian.org

Cc: 374640@bugs.debian.org, 374640-submitter@bugs.debian.org

Subject: Re: gedit: freeze when XIM is used to input Japanese

Date: Sun, 19 Nov 2006 22:58:29 +0900

[Message part 1 (text/plain, inline)]

Hi people involved with imput method packages,

http://bugs.debian.org/374640  Any comments on this bug?
   (I posted request for help to Japanese debian list too.)

Now that we are facing this gedit bug#374640 with xim for UIM and SCIM,
how are your package affected?  I want to know the extent of the
problem.

Do you think we should change default input path to use immodule instead
of xim for SCIM and UIM?  At least it avoid major problem.  I do not see
much CPP ABI issues lately too which prompted SCIM to use xim.

If any one of you can fix this gedit bug, that is also good too.

Thanks in advance,

Osamu

[signature.asc (application/pgp-signature, inline)]

Message #87 received at 374640@bugs.debian.org (full text, mbox, reply):

From: Josselin Mouette <joss@debian.org>

To: Osamu Aoki <osamu@debian.org>, 374640@bugs.debian.org

Subject: Re: Bug#374640: gedit: freeze when XIM is used to input Japanese

Date: Sun, 19 Nov 2006 17:30:19 +0100

[Message part 1 (text/plain, inline)]

Le dimanche 19 novembre 2006 à 22:26 +0900, Osamu Aoki a écrit :
> >  Can you please rebuild gedit with debugging symbols and get a backtrace
> >  of all threads during a freeze?  If you're not familiar with gdb,
> >  <http://wiki.debian.org/HowToGetABacktrace> has the details.
> 
> Done but
> 
> "If you're lucky, a crash will occur and you'll be dropped back to the
> gdb prompt. At that point, you can run:"
> 
> Well, it just freezes screen without giving me prompt.

Just use Control-C at that moment to generate an interrupt signal.

-- 
Josselin Mouette                /\./\

"Do you have any more insane proposals for me?"

[signature.asc (application/pgp-signature, inline)]

Message #92 received at 374640@bugs.debian.org (full text, mbox, reply):

From: Loïc Minier <lool@dooz.org>

To: Osamu Aoki <osamu@debian.org>

Cc: 374640@bugs.debian.org, 374640-submitter@bugs.debian.org, kmuto@debian.org

Subject: Re: gedit: freeze when XIM is used to input Japanese

Date: Sun, 19 Nov 2006 17:33:19 +0100

On Sun, Nov 19, 2006, Osamu Aoki wrote:
> Well, it just freezes screen without giving me prompt.

 ^C in the terminal where you run gdb, should get you back to gdb.

-- 
Loïc Minier <lool@dooz.org>
        10 SIN
        20 GO TO ROBOT HELL             -- Temple of Robotology

Message #100 received at 374640@bugs.debian.org (full text, mbox, reply):

From: Osamu Aoki <osamu@debian.org>

To: Loïc Minier <lool@dooz.org>

Cc: 374640@bugs.debian.org

Subject: Re: gedit: freeze when XIM is used to input Japanese

Date: Mon, 20 Nov 2006 02:03:40 +0900

On Sun, Nov 19, 2006 at 05:33:19PM +0100, Loïc Minier wrote:
> On Sun, Nov 19, 2006, Osamu Aoki wrote:
> > Well, it just freezes screen without giving me prompt.
> 
>  ^C in the terminal where you run gdb, should get you back to gdb.

I see.  Voila!

------------------
(gdb) set pagination 0
(gdb) run
Starting program: /usr/bin/gedit
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread -1225324864 (LWP 5797)]

Program received signal SIGINT, Interrupt.
[Switching to Thread -1225324864 (LWP 5797)]
0xb7634bda in g_param_value_validate () from /usr/lib/libgobject-2.0.so.0
(gdb) thread apply all bt

Thread 1 (Thread -1225324864 (LWP 5797)):
#0  0xb7634bda in g_param_value_validate () from /usr/lib/libgobject-2.0.so.0
#1  0xb7b5ed84 in gtk_settings_get_default () from /usr/lib/libgtk-x11-2.0.so.0
#2  0xb762fdf1 in g_object_get_valist () from /usr/lib/libgobject-2.0.so.0
#3  0xb7630037 in g_object_get () from /usr/lib/libgobject-2.0.so.0
#4  0xb7ba692f in _gtk_text_util_append_special_char_menuitems () from /usr/lib/libgtk-x11-2.0.so.0
#5  0xb7ba697d in _gtk_text_util_append_special_char_menuitems () from /usr/lib/libgtk-x11-2.0.so.0
#6  0xb7bb2737 in gtk_text_view_new_with_buffer () from /usr/lib/libgtk-x11-2.0.so.0
#7  0xb7f99e33 in gtk_source_view_get_show_line_numbers () from /usr/lib/libgtksourceview-1.0.so.0
#8  0xb7b17250 in _gtk_marshal_BOOLEAN__BOXED () from /usr/lib/libgtk-x11-2.0.so.0
#9  0xb762af49 in g_value_set_boxed () from /usr/lib/libgobject-2.0.so.0
#10 0xb762ca7c in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#11 0xb763d56f in g_signal_chain_from_overridden () from /usr/lib/libgobject-2.0.so.0
#12 0xb763e208 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#13 0xb763e5d9 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#14 0xb7c00e84 in gtk_widget_get_default_style () from /usr/lib/libgtk-x11-2.0.so.0
#15 0x0809e667 in gedit_window_key_press_event (widget=0x812e008, event=0xbfe97ec8) at gedit-window.c:228
#16 0xb7b17250 in _gtk_marshal_BOOLEAN__BOXED () from /usr/lib/libgtk-x11-2.0.so.0
#17 0xb762af49 in g_value_set_boxed () from /usr/lib/libgobject-2.0.so.0
#18 0xb762c98b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#19 0xb763d56f in g_signal_chain_from_overridden () from /usr/lib/libgobject-2.0.so.0
#20 0xb763e208 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#21 0xb763e5d9 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#22 0xb7c00e84 in gtk_widget_get_default_style () from /usr/lib/libgtk-x11-2.0.so.0
#23 0xb7b10c0a in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0
#24 0xb7b11e07 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0
#25 0xb79aaeea in _gdk_events_init () from /usr/lib/libgdk-x11-2.0.so.0
#26 0xb75bc731 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#27 0xb75bf7a6 in g_main_context_check () from /usr/lib/libglib-2.0.so.0
#28 0xb75bfb67 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#29 0xb7b12281 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#30 0x08066e85 in main (argc=1, argv=0xbfe986a4) at gedit.c:566
(gdb) 
-----------------

Message #105 received at 374640@bugs.debian.org (full text, mbox, reply):

From: Loïc Minier <lool@dooz.org>

To: Osamu Aoki <osamu@debian.org>

Cc: 374640@bugs.debian.org

Subject: Re: gedit: freeze when XIM is used to input Japanese

Date: Sun, 19 Nov 2006 18:10:27 +0100

On Mon, Nov 20, 2006, Osamu Aoki wrote:
> I see.  Voila!

 Can you please refresh this backtrace after you have installed
 libgtk2.0-dbg and libglib2.0-0-dbg?

   Thanks,
-- 
Loïc Minier <lool@dooz.org>
        10 SIN
        20 GO TO ROBOT HELL             -- Temple of Robotology

Message #110 received at 374640@bugs.debian.org (full text, mbox, reply):

From: Osamu Aoki <osamu@debian.org>

To: Loïc Minier <lool@dooz.org>

Cc: 374640@bugs.debian.org

Subject: Re: gedit: freeze when XIM is used to input Japanese

Date: Mon, 20 Nov 2006 02:26:11 +0900

On Sun, Nov 19, 2006 at 06:10:27PM +0100, Loïc Minier wrote:
> On Mon, Nov 20, 2006, Osamu Aoki wrote:
> > I see.  Voila!
> 
>  Can you please refresh this backtrace after you have installed
>  libgtk2.0-dbg and libglib2.0-0-dbg?

You mean libgtk2.0-0-dbg

---------------------
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".

(gdb) set pagination 0
(gdb) run
Starting program: /usr/bin/gedit
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread -1225505088 (LWP 6662)]

Program received signal SIGINT, Interrupt.
[Switching to Thread -1225505088 (LWP 6662)]
0xb78078d8 in XIfEvent () from /usr/lib/libX11.so.6
(gdb) thread apply all bt full

Thread 1 (Thread -1225505088 (LWP 6662)):
#0  0xb78078d8 in XIfEvent () from /usr/lib/libX11.so.6
No symbol table info available.
#1  0xb7855c3b in _XimXConf () from /usr/lib/libX11.so.6
No symbol table info available.
#2  0xb7855232 in _XimFlush () from /usr/lib/libX11.so.6
No symbol table info available.
#3  0xb78555d3 in _XimRead () from /usr/lib/libX11.so.6
No symbol table info available.
#4  0xb7847878 in _XimForwardEvent () from /usr/lib/libX11.so.6
No symbol table info available.
#5  0xb7841828 in _XimRegisterFilter () from /usr/lib/libX11.so.6
No symbol table info available.
#6  0xb7801494 in XFilterEvent () from /usr/lib/libX11.so.6
No symbol table info available.
#7  0xb63ccaae in gtk_im_context_xim_filter_keypress (context=0x81c2990, event=0x81c8f40) at gtkimcontextxim.c:728
        context_xim = <value optimized out>
        ic = (XIC) 0x841c2e8
        static_buffer = "\000\000\000\000\000\000\000\000�tU�\000\000\000\000\030\000\000\000�\004\000\000\004\000\000\000\000)V��(V��\034ʷQ\216I�\030\000\000\000�$V�x\000\000\000Q\216I��$V�(\000\000\000H�ؿ�\017V��$V�\230\213D\bX�ؿ�\225I�y\000\000\000\210�N\bx\031\000\000XuU�\000\000\000\000x�ؿ1{Y�\230\213D\b�$V�\002\000\000\000�\034ʷ�\034ʷб/\bصؿ\222ֵ�\230\213D\b�$V��\205D\b��ؿ�\017V��$V�\030�N\b��ؿ�\225I��$V�\030�N\b�a_�"...
        buffer = <value optimized out>
        buffer_size = <value optimized out>
        num_bytes = <value optimized out>
        keysym = 3057437131
        status = <value optimized out>
        result = -1076316920
        root_window = (GdkWindow *) 0x80f3408
        xevent = {type = 2, serial = 0, send_event = 0, display = 0x80eb178, window = 48234499, root = 76, subwindow = 48234499, time = 20837946, x = 0, y = 0, x_root = 0, y_root = 0, state = 0, keycode = 50, same_screen = 1}
#8  0xb7aca273 in IA__gtk_im_context_filter_keypress (context=0x81c2990, key=0x81c8f40) at gtkimcontext.c:317
        __PRETTY_FUNCTION__ = "IA__gtk_im_context_filter_keypress"
#9  0xb7accc35 in gtk_im_multicontext_filter_keypress (context=0x81ac138, event=0x81c8f40) at gtkimmulticontext.c:316
        slave = (GtkIMContext *) 0x80f1780
#10 0xb7aca273 in IA__gtk_im_context_filter_keypress (context=0x81ac138, key=0x81c8f40) at gtkimcontext.c:317
        __PRETTY_FUNCTION__ = "IA__gtk_im_context_filter_keypress"
#11 0xb7b867a9 in gtk_text_view_key_press_event (widget=0x81333b0, event=0x81c8f40) at gtktextview.c:3868
        retval = <value optimized out>
        text_view = <value optimized out>
        insert = <value optimized out>
        iter = {dummy1 = 0x82f9cc0, dummy2 = 0x82fa3c8, dummy3 = 0, dummy4 = -1, dummy5 = -1, dummy6 = -1, dummy7 = -345134441, dummy8 = -1629212296, dummy9 = 0x82fb1d0, dummy10 = 0x82fb2c0, dummy11 = 0, dummy12 = -1, dummy13 = 136063120, dummy14 = 0xbfd8b718}
        can_insert = <value optimized out>
#12 0xb7f6de33 in gtk_source_view_get_show_line_numbers () from /usr/lib/libgtksourceview-1.0.so.0
No symbol table info available.
#13 0xb7aeb250 in _gtk_marshal_BOOLEAN__BOXED (closure=0x814f758, return_value=0xbfd8ba50, n_param_values=2, param_values=0xbfd8bb2c, invocation_hint=0xbfd8ba3c, marshal_data=0x81333b0) at gtkmarshalers.c:83
        data1 = (gpointer) 0x81c2890
        data2 = <value optimized out>
        v_return = <value optimized out>
        __PRETTY_FUNCTION__ = "_gtk_marshal_BOOLEAN__BOXED"
#14 0xb75fef49 in g_type_class_meta_marshal (closure=0x814f758, return_value=0xbfd8ba50, n_param_values=2, param_values=0xbfd8bb2c, invocation_hint=0xbfd8ba3c, marshal_data=0xcc) at gclosure.c:567
        callback = <value optimized out>
#15 0xb7600a7c in IA__g_closure_invoke (closure=0x814f758, return_value=0xbfd8ba50, n_param_values=2, param_values=0xbfd8bb2c, invocation_hint=0xbfd8ba3c) at gclosure.c:490
        marshal = (GClosureMarshal) 0xb75fef00 <g_type_class_meta_marshal>
        marshal_data = (gpointer) 0xcc
        __PRETTY_FUNCTION__ = "IA__g_closure_invoke"
#16 0xb761156f in signal_emit_unlocked_R (node=0x814f6d8, detail=0, instance=0x81333b0, emission_return=0xbfd8bcec, instance_and_params=0xbfd8bb2c) at gsignal.c:2478
        tmp = <value optimized out>
        handler = (Handler *) 0xbfd8ba08
        accumulator = (SignalAccumulator *) 0x80ff0e8
        emission = {next = 0xbfd8bf54, instance = 0x81333b0, ihint = {signal_id = 50, detail = 0, run_type = G_SIGNAL_RUN_LAST}, state = EMISSION_RUN, chain_type = 136971728}
        class_closure = (GClosure *) 0x814f758
        handler_list = (Handler *) 0x0
        return_accu = (GValue *) 0xbfd8ba50
        accu = {g_type = 20, data = {{v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0}, {v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0}}}
        signal_id = 50
        max_sequential_handler_number = 1612
        return_value_altered = 0
#17 0xb7612208 in IA__g_signal_emit_valist (instance=0x81333b0, signal_id=50, detail=0, var_args=0xbfd8bd70 "\210�ؿ@\217\034\b�3\023\b_\220���3\023\bH�\024\b") at gsignal.c:2209
        _flags = <value optimized out>
        _vtable = <value optimized out>
        _cvalues = {{v_int = -1076314744, v_long = -1076314744, v_int64 = 3218652552, v_double = 1.5902256518424564e-314, v_pointer = 0xbfd8bd88}, {v_int = 0, v_long = 0, v_int64 = 0, v_double = 0, v_pointer = 0x0}, {v_int = 0, v_long = 0, v_int64 = 0, v_double = 0, v_pointer = 0x0}, {v_int = 0, v_long = 0, v_int64 = 0, v_double = 0, v_pointer = 0x0}, {v_int = 0, v_long = 0, v_int64 = 0, v_double = 0, v_pointer = 0x0}, {v_int = 0, v_long = 0, v_int64 = 0, v_double = 0, v_pointer = 0x0}, {v_int = 0, v_long = 0, v_int64 = 0, v_double = 0, v_pointer = 0x0}, {v_int = 0, v_long = 0, v_int64 = 0, v_double = 0, v_pointer = 0x0}}
        _lcopy_format = <value optimized out>
        _n_values = <value optimized out>
        return_value = {g_type = 20, data = {{v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0}, {v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0}}}
        error = <value optimized out>
        instance_and_params = (GValue *) 0xbfd8bb2c
        stack_values = {{g_type = 136971728, data = {{v_int = 135476144, v_uint = 135476144, v_long = 135476144, v_ulong = 135476144, v_int64 = 135476144, v_uint64 = 135476144, v_float = 4.42969618e-34, v_double = 6.6934108581441718e-316, v_pointer = 0x81333b0}, {v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0}}}, {g_type = 135237632, data = {{v_int = 136089408, v_uint = 136089408, v_long = 136089408, v_ulong = 136089408, v_int64 = 136089408, v_uint64 = 136089408, v_float = 4.7112932e-34, v_double = 6.7237101255672904e-316, v_pointer = 0x81c8f40}, {v_int = 134217728, v_uint = 134217728, v_long = 134217728, v_ulong = 134217728, v_int64 = 134217728, v_uint64 = 134217728, v_float = 3.85185989e-34, v_double = 6.631236846766476e-316, v_pointer = 0x8000000}}}, {g_type = 3075876040, data = {{v_int = 16, v_uint = 16, v_long = 16, v_ulong = 16, v_int64 = 16, v_uint64 = 16, v_float = 2.24207754e-44, v_double = 7.9050503334599447e-323, v_pointer = 0x10}, {v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0}}}, {g_type = 0, data = {{v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0}, {v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0}}}, {g_type = 0, data = {{v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = 73014444032, v_uint64 = 73014444032, v_float = 0, v_double = 3.6073928446409629e-313, v_pointer = 0x0}, {v_int = -1076315208, v_uint = 3218652088, v_long = -1076315208, v_ulong = 3218652088, v_int64 = -5235015898777470024, v_uint64 = 13211728174932081592, v_float = -1.69322872, v_double = -4.5715795500614964e-42, v_pointer = 0xbfd8bbb8}}}, {g_type = 3075051089, data = {{v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0}, {v_int = -1218337999, v_uint = 3076629297, v_long = -1218337999, v_ulong = 3076629297, v_int64 = -5239448468377722063, v_uint64 = 13207295605331829553, v_float = -1.3449041e-05, v_double = -2.3084212473607347e-42, v_pointer = 0xb761a331}}}, {g_type = 1, data = {{v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = -5233356610100789248, v_uint64 = 13213387463608762368, v_float = 0, v_double = -5.6289392976830224e-42, v_pointer = 0x0}, {v_int = 4, v_uint = 4, v_long = 4, v_ulong = 4, v_int64 = 107374182404, v_uint64 = 107374182404, v_float = 5.60519386e-45, v_double = 5.304989477610807e-313, v_pointer = 0x4}}}, {g_type = 3218652120, data = {{v_int = -1218793298, v_uint = 3076173998, v_long = -1218793298, v_ulong = 3076173998, v_int64 = -5236150397351317330, v_uint64 = 13210593676358234286, v_float = -1.3034949e-05, v_double = -3.8486353495865179e-42, v_pointer = 0xb75ab0ae}, {v_int = 138708208, v_uint = 138708208, v_long = 138708208, v_ulong = 138708208, v_int64 = 17318577392, v_uint64 = 17318577392, v_float = 5.91378718e-34, v_double = 8.5565141242300912e-314, v_pointer = 0x84484f0}}}, {g_type = 3076720368, data = {{v_int = -1219096588, v_uint = 3075870708, v_long = -1219096588, v_ulong = 3075870708, v_int64 = -5239488858250932236, v_uint64 = 13207255215458619380, v_float = -1.27591084e-05, v_double = -2.2955522913001763e-42, v_pointer = 0xb7560ff4}, {v_int = 138708208, v_uint = 138708208, v_long = 138708208, v_ulong = 138708208, v_int64 = -4622738343530822416, v_uint64 = 13824005730178729200, v_float = 5.91378718e-34, v_double = -0.3864727097262195, v_pointer = 0x84484f0}}}, {g_type = 3075052994, data = {{v_int = -1219091264, v_uint = 3075876032, v_long = -1219091264, v_ulong = 3075876032, v_int64 = 595747220122641600, v_uint64 = 595747220122641600, v_float = -1.27639505e-05, v_double = 7.7681281284407345e-269, v_pointer = 0xb75624c0}, {v_int = -1218485788, v_uint = 3076481508, v_long = -1218485788, v_ulong = 3076481508, v_int64 = 595747220123247076, v_uint64 = 595747220123247076, v_float = -1.33146277e-05, v_double = 7.7681281292550844e-269, v_pointer = 0xb75f61e4}}}, {g_type = 3218652264, data = {{v_int = -1076315112, v_uint = 3218652184, v_long = -1076315112, v_ulong = 3218652184, v_int64 = -5235017638239224808, v_uint64 = 13211726435470326808, v_float = -1.69324017, v_double = -4.5704711010809881e-42, v_pointer = 0xbfd8bc18}, {v_int = -1219096588, v_uint = 3075870708, v_long = -1219096588, v_ulong = 3075870708, v_int64 = -5235957106643431436, v_uint64 = 13210786967066120180, v_float = -1.27591084e-05, v_double = -3.9718072948785512e-42, v_pointer = 0xb7560ff4}}}, {g_type = 138708608, data = {{v_int = -1076315096, v_uint = 3218652200, v_long = -1076315096, v_ulong = 3218652200, v_int64 = 71938128936, v_uint64 = 71938128936, v_float = -1.69324207, v_double = 3.5542158133375706e-313, v_pointer = 0xbfd8bc28}, {v_int = -1219091256, v_uint = 3075876040, v_long = -1219091256, v_ulong = 3075876040, v_int64 = 595748938109560008, v_uint64 = 595748938109560008, v_float = -1.27639578e-05, v_double = 7.7704387772418523e-269, v_pointer = 0xb75624c8}}}, {g_type = 3076640577, data = {{v_int = -1219916207, v_uint = 3075051089, v_long = -1219916207, v_ulong = 3075051089, v_int64 = -4622737859558142383, v_uint64 = 13824006214151409233, v_float = -1.20136692e-05, v_double = -0.38649957560685261, v_pointer = 0xb7498e51}, {v_int = -1076315064, v_uint = 3218652232, v_long = -1076315064, v_ulong = 3218652232, v_int64 = -5232959077594121144, v_uint64 = 13213784996115430472, v_float = -1.69324589, v_double = -6.0248047421197254e-42, v_pointer = 0xbfd8bc48}}}, {g_type = 138708608, data = {{v_int = 1083922840, v_uint = 1083922840, v_long = 1083922840, v_ulong = 1083922840, v_int64 = 1083922840, v_uint64 = 1083922840, v_float = 4.85468674, v_double = 5.3552903798667814e-315, v_pointer = 0x409b5998}, {v_int = -1218246928, v_uint = 3076720368, v_long = -1218246928, v_ulong = 3076720368, v_int64 = 582574864664299248, v_uint64 = 582574864664299248, v_float = -1.35318696e-05, v_double = 1.0279157429243026e-269, v_pointer = 0xb76306f0}}}, {g_type = 17, data = {{v_int = -1076314984, v_uint = 3218652312, v_long = -1076314984, v_ulong = 3218652312, v_int64 = -5233029016841569128, v_uint64 = 13213715056867982488, v_float = -1.69325542, v_double = -5.9356690226156659e-42, v_pointer = 0xbfd8bc98}, {v_int = -1219136268, v_uint = 3075831028, v_long = -1219136268, v_ulong = 3075831028, v_int64 = -4622736622606781196, v_uint64 = 13824007451102770420, v_float = -1.27230196e-05, v_double = -0.38656824020092917, v_pointer = 0xb75574f4}}}, {g_type = 3218652296, data = {{v_int = -1218303996, v_uint = 3076663300, v_long = -1218303996, v_ulong = 3076663300, v_int64 = 106155878404, v_uint64 = 106155878404, v_float = -1.34799666e-05, v_double = 5.2447972623517096e-313, v_pointer = 0xb7622804}, {v_int = 64, v_uint = 64, v_long = 64, v_ulong = 64, v_int64 = 64, v_uint64 = 64, v_float = 8.96831017e-44, v_double = 3.1620201333839779e-322, v_pointer = 0x40}}}}
        free_me = (GValue *) 0x0
        signal_return_type = 20
        param_values = (GValue *) 0xbfd8bb40
        node = (SignalNode *) 0x814f6d8
        i = 1
        n_params = 1
        __PRETTY_FUNCTION__ = "IA__g_signal_emit_valist"
#18 0xb76125d9 in IA__g_signal_emit (instance=0x81333b0, signal_id=50, detail=0) at gsignal.c:2243
        var_args = 0xbfd8bd6c "@\217\034\b\210�ؿ@\217\034\b�3\023\b_\220���3\023\bH�\024\b"
#19 0xb7bd4e84 in gtk_widget_event_internal (widget=0x81333b0, event=0x81c8f40) at gtkwidget.c:3751
        signal_num = <value optimized out>
        return_val = 0
#20 0xb7be4286 in IA__gtk_window_propagate_key_event (window=0x812d008, event=0x81c8f40) at gtkwindow.c:4517
        parent = (GtkWidget *) 0x812d008
        handled = 0
        focus = (GtkWidget *) 0x81333b0
        __PRETTY_FUNCTION__ = "IA__gtk_window_propagate_key_event"
#21 0xb7be70dc in gtk_window_key_press_event (widget=0x812d008, event=0x81c8f40) at gtkwindow.c:4547
        handled = 0
#22 0xb7aeb250 in _gtk_marshal_BOOLEAN__BOXED (closure=0x814f758, return_value=0xbfd8bf70, n_param_values=2, param_values=0xbfd8c04c, invocation_hint=0xbfd8bf5c, marshal_data=0x809e630) at gtkmarshalers.c:83
        data1 = (gpointer) 0x812d008
        data2 = <value optimized out>
        v_return = <value optimized out>
        __PRETTY_FUNCTION__ = "_gtk_marshal_BOOLEAN__BOXED"
#23 0xb75fef49 in g_type_class_meta_marshal (closure=0x814f758, return_value=0xbfd8bf70, n_param_values=2, param_values=0xbfd8c04c, invocation_hint=0xbfd8bf5c, marshal_data=0xcc) at gclosure.c:567
        callback = <value optimized out>
#24 0xb760098b in IA__g_closure_invoke (closure=0x814f758, return_value=0xbfd8bf70, n_param_values=2, param_values=0xbfd8c04c, invocation_hint=0xbfd8bf5c) at gclosure.c:490
        marshal = (GClosureMarshal) 0xb75fef00 <g_type_class_meta_marshal>
        marshal_data = (gpointer) 0xcc
        __PRETTY_FUNCTION__ = "IA__g_closure_invoke"
#25 0xb761156f in signal_emit_unlocked_R (node=0x814f6d8, detail=0, instance=0x812d008, emission_return=0xbfd8c20c, instance_and_params=0xbfd8c04c) at gsignal.c:2478
        tmp = <value optimized out>
        handler = (Handler *) 0xbfd8bf28
        accumulator = (SignalAccumulator *) 0x80ff0e8
        emission = {next = 0x0, instance = 0x812d008, ihint = {signal_id = 50, detail = 0, run_type = G_SIGNAL_RUN_LAST}, state = EMISSION_RUN, chain_type = 135602808}
        class_closure = (GClosure *) 0x814f758
        handler_list = (Handler *) 0x81a5200
        return_accu = (GValue *) 0xbfd8bf70
        accu = {g_type = 20, data = {{v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0}, {v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0}}}
        signal_id = 50
        max_sequential_handler_number = 1612
        return_value_altered = 1
#26 0xb7612208 in IA__g_signal_emit_valist (instance=0x812d008, signal_id=50, detail=0, var_args=0xbfd8c290 "��ؿ@\217\034\b\b�\022\b_\220��\b�\022\bH�\024\b") at gsignal.c:2209
        _flags = <value optimized out>
        _vtable = <value optimized out>
        _cvalues = {{v_int = -1076313432, v_long = -1076313432, v_int64 = 3218653864, v_double = 1.5902263000565837e-314, v_pointer = 0xbfd8c2a8}, {v_int = 0, v_long = 0, v_int64 = 0, v_double = 0, v_pointer = 0x0}, {v_int = 0, v_long = 0, v_int64 = 0, v_double = 0, v_pointer = 0x0}, {v_int = 0, v_long = 0, v_int64 = 0, v_double = 0, v_pointer = 0x0}, {v_int = 0, v_long = 0, v_int64 = 0, v_double = 0, v_pointer = 0x0}, {v_int = 0, v_long = 0, v_int64 = 0, v_double = 0, v_pointer = 0x0}, {v_int = 0, v_long = 0, v_int64 = 0, v_double = 0, v_pointer = 0x0}, {v_int = 0, v_long = 0, v_int64 = 0, v_double = 0, v_pointer = 0x0}}
        _lcopy_format = <value optimized out>
        _n_values = <value optimized out>
        return_value = {g_type = 20, data = {{v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0}, {v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0}}}
        error = <value optimized out>
        instance_and_params = (GValue *) 0xbfd8c04c
        stack_values = {{g_type = 135602808, data = {{v_int = 135450632, v_uint = 135450632, v_long = 135450632, v_ulong = 135450632, v_int64 = 135450632, v_uint64 = 135450632, v_float = 4.41798164e-34, v_double = 6.6921503978685016e-316, v_pointer = 0x812d008}, {v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0}}}, {g_type = 135237632, data = {{v_int = 136089408, v_uint = 136089408, v_long = 136089408, v_ulong = 136089408, v_int64 = 136089408, v_uint64 = 136089408, v_float = 4.7112932e-34, v_double = 6.7237101255672904e-316, v_pointer = 0x81c8f40}, {v_int = 134217728, v_uint = 134217728, v_long = 134217728, v_ulong = 134217728, v_int64 = 134217728, v_uint64 = 134217728, v_float = 3.85185989e-34, v_double = 6.631236846766476e-316, v_pointer = 0x8000000}}}, {g_type = 1087100224, data = {{v_int = -1215004974, v_uint = 3079962322, v_long = -1215004974, v_ulong = 3079962322, v_int64 = -5216364187389493550, v_uint64 = 13230379886320058066, v_float = -1.77020302e-05, v_double = -7.9643179947160655e-41, v_pointer = 0xb7947ed2}, {v_int = 137881832, v_uint = 137881832, v_long = 137881832, v_ulong = 137881832, v_int64 = 583442445119252712, v_uint64 = 583442445119252712, v_float = 5.53433393e-34, v_double = 1.1737749544112757e-269, v_pointer = 0x837e8e8}}}, {g_type = 3218653352, data = {{v_int = -1214800503, v_uint = 3080166793, v_long = -1214800503, v_ulong = 3080166793, v_int64 = 592197962232733065, v_uint64 = 592197962232733065, v_float = -1.80739607e-05, v_double = 4.5258467716133138e-269, v_pointer = 0xb7979d89}, {v_int = 135208800, v_uint = 135208800, v_long = 135208800, v_ulong = 135208800, v_int64 = -4622733120854089888, v_uint64 = 13824010952855461728, v_float = 4.30693783e-34, v_double = -0.38676262652415083, v_pointer = 0x80f1f60}}}, {g_type = 3076014391, data = {{v_int = 92, v_uint = 92, v_long = 92, v_ulong = 92, v_int64 = -5216492476847620004, v_uint64 = 13230251596861931612, v_float = 1.28919459e-43, v_double = -7.8335167799801811e-41, v_pointer = 0x5c}, {v_int = -1076313912, v_uint = 3218653384, v_long = -1076313912, v_ulong = 3218653384, v_int64 = -5216364187250802488, v_uint64 = 13230379886458749128, v_float = -1.69338322, v_double = -7.9643181361225352e-41, v_pointer = 0xbfd8c0c8}}}, {g_type = 135201000, data = {{v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = -4622732983550345216, v_uint64 = 13824011090159206400, v_float = 0, v_double = -0.38677024841308594, v_pointer = 0x0}, {v_int = -1214738605, v_uint = 3080228691, v_long = -1214738605, v_ulong = 3080228691, v_int64 = 580370756170977107, v_uint64 = 580370756170977107, v_float = -1.81865526e-05, v_double = 7.0725519721366868e-270, v_pointer = 0xb7988f53}}}, {g_type = 92, data = {{v_int = -1214739253, v_uint = 3080228043, v_long = -1214739253, v_ulong = 3080228043, v_int64 = -5224263190592320309, v_uint64 = 13222480883117231307, v_float = -1.81853738e-05, v_double = -2.2735528052795738e-41, v_pointer = 0xb7988ccb}, {v_int = 135182472, v_uint = 135182472, v_long = 135182472, v_ulong = 135182472, v_int64 = -4622732433659348856, v_uint64 = 13824011640050202760, v_float = 4.29484861e-34, v_double = -0.38680077349534558, v_pointer = 0x80eb888}}}, {g_type = 4, data = {{v_int = -1214737632, v_uint = 3080229664, v_long = -1214737632, v_ulong = 3080229664, v_int64 = 580683876466725664, v_uint64 = 580683876466725664, v_float = -1.81883224e-05, v_double = 7.3357637536936038e-270, v_pointer = 0xb7989320}, {v_int = 135199160, v_uint = 135199160, v_long = 135199160, v_ulong = 135199160, v_int64 = 25905002936, v_uint64 = 25905002936, v_float = 4.30251136e-34, v_double = 1.2798772006094228e-313, v_pointer = 0x80ef9b8}}}, {g_type = 3080437864, data = {{v_int = 135201000, v_uint = 135201000, v_long = 135201000, v_ulong = 135201000, v_int64 = 583442445116571880, v_uint64 = 583442445116571880, v_float = 4.30335625e-34, v_double = 1.1737749539605694e-269, v_pointer = 0x80f00e8}, {v_int = -1076313832, v_uint = 3218653464, v_long = -1076313832, v_ulong = 3218653464, v_int64 = -5217256449526677224, v_uint64 = 13229487624182874392, v_float = -1.69339275, v_double = -7.0545864149675435e-41, v_pointer = 0xbfd8c118}}}, {g_type = 135201000, data = {{v_int = 92, v_uint = 92, v_long = 92, v_ulong = 92, v_int64 = 4294967388, v_uint64 = 4294967388, v_float = 1.28919459e-43, v_double = 2.1219958364193117e-314, v_pointer = 0x5c}, {v_int = -1214529432, v_uint = 3080437864, v_long = -1214529432, v_ulong = 3080437864, v_int64 = 580683876466933864, v_uint64 = 580683876466933864, v_float = -1.8567036e-05, v_double = 7.3357637538686186e-270, v_pointer = 0xb79bc068}}}, {g_type = 135843280, data = {{v_int = -1076313752, v_uint = 3218653544, v_long = -1076313752, v_ulong = 3218653544, v_int64 = -5217171460713823896, v_uint64 = 13229572612995727720, v_float = -1.69340229, v_double = -7.141239208755311e-41, v_pointer = 0xbfd8c168}, {v_int = 135180664, v_uint = 135180664, v_long = 135180664, v_ulong = 135180664, v_int64 = 207165595879125368, v_uint64 = 207165595879125368, v_float = 4.29401842e-34, v_double = 7.8288052896017078e-295, v_pointer = 0x80eb178}}}, {g_type = 290, data = {{v_int = -1218333036, v_uint = 3076634260, v_long = -1218333036, v_ulong = 3076634260, v_int64 = 140515587732, v_uint64 = 140515587732, v_float = -1.34535549e-05, v_double = 6.942392460357292e-313, v_pointer = 0xb761b694}, {v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = -4622732433794531328, v_uint64 = 13824011639915020288, v_float = 0, v_double = -0.38680076599121094, v_pointer = 0x0}}}, {g_type = 3076634260, data = {{v_int = -1214870631, v_uint = 3080096665, v_long = -1214870631, v_ulong = 3080096665, v_int64 = 4672697200178269081, v_uint64 = 4672697200178269081, v_float = -1.79463987e-05, v_double = 25349.386205326391, v_pointer = 0xb7968b99}, {v_int = 138582040, v_uint = 138582040, v_long = 138582040, v_ulong = 138582040, v_int64 = -5232330714073884648, v_uint64 = 13214413359635666968, v_float = 5.85585368e-34, v_double = -6.8256374151913052e-42, v_pointer = 0x8429818}}}, {g_type = 135843280, data = {{v_int = 76, v_uint = 76, v_long = 76, v_ulong = 76, v_int64 = -4622732227636101044, v_uint64 = 13824011846073450572, v_float = 1.06498683e-43, v_double = -0.38681221008301203, v_pointer = 0x4c}, {v_int = -1218434050, v_uint = 3076533246, v_long = -1218434050, v_ulong = 3076533246, v_int64 = 583442465237773310, v_uint64 = 583442465237773310, v_float = -1.33616832e-05, v_double = 1.1737783367737229e-269, v_pointer = 0xb7602bfe}}}, {g_type = 76, data = {{v_int = 75, v_uint = 75, v_long = 75, v_ulong = 75, v_int64 = -5233136085004976053, v_uint64 = 13213607988704575563, v_float = 1.05097385e-43, v_double = -5.7992134825649621e-42, v_pointer = 0x4b}, {v_int = 135843284, v_uint = 135843284, v_long = 135843284, v_ulong = 135843284, v_int64 = 4430810580, v_uint64 = 4430810580, v_float = 4.5982786e-34, v_double = 2.1891112908079282e-314, v_pointer = 0x818cdd4}}}, {g_type = 135843284, data = {{v_int = -1214529432, v_uint = 3080437864, v_long = -1214529432, v_ulong = 3080437864, v_int64 = 583442448061808744, v_uint64 = 583442448061808744, v_float = -1.8567036e-05, v_double = 1.173775449119173e-269, v_pointer = 0xb79bc068}, {v_int = 1, v_uint = 1, v_long = 1, v_ulong = 1, v_int64 = -4622730990685519871, v_uint64 = 13824013083024031745, v_float = 1.40129846e-45, v_double = -0.38688087463378912, v_pointer = 0x1}}}}
        free_me = (GValue *) 0x0
        signal_return_type = 20
        param_values = (GValue *) 0xbfd8c060
        node = (SignalNode *) 0x814f6d8
        i = 1
        n_params = 1
        __PRETTY_FUNCTION__ = "IA__g_signal_emit_valist"
#27 0xb76125d9 in IA__g_signal_emit (instance=0x812d008, signal_id=50, detail=0) at gsignal.c:2243
        var_args = 0xbfd8c28c "@\217\034\b��ؿ@\217\034\b\b�\022\b_\220��\b�\022\bH�\024\b"
#28 0xb7bd4e84 in gtk_widget_event_internal (widget=0x812d008, event=0x81c8f40) at gtkwidget.c:3751
        signal_num = <value optimized out>
        return_val = 0
#29 0xb7ae4c0a in IA__gtk_propagate_event (widget=0x812d008, event=0x81c8f40) at gtkmain.c:2169
        window = (GtkWidget *) 0x812d008
        handled_event = <value optimized out>
        __PRETTY_FUNCTION__ = "IA__gtk_propagate_event"
#30 0xb7ae5e07 in IA__gtk_main_do_event (event=0x81c8f40) at gtkmain.c:1424
        event_widget = (GtkWidget *) 0x812d008
        grab_widget = (GtkWidget *) 0x812d008
        window_group = (GtkWindowGroup *) 0x815d960
        next_event = <value optimized out>
        rewritten_event = (GdkEvent *) 0x0
        tmp_list = <value optimized out>
        __PRETTY_FUNCTION__ = "IA__gtk_main_do_event"
#31 0xb797eeea in gdk_event_dispatch (source=0x80f5be0, callback=0, user_data=0x0) at gdkevents-x11.c:2291
        display = <value optimized out>
        event = (GdkEvent *) 0x81c8f40
#32 0xb7590731 in IA__g_main_context_dispatch (context=0x80f5c28) at gmain.c:2045
No locals.
#33 0xb75937a6 in g_main_context_iterate (context=0x80f5c28, block=1, dispatch=1, self=0x80dc688) at gmain.c:2677
        got_ownership = <value optimized out>
        max_priority = 0
        timeout = 0
        some_ready = 1
        nfds = <value optimized out>
        allocated_nfds = <value optimized out>
        fds = (GPollFD *) 0x8179e90
        __PRETTY_FUNCTION__ = "g_main_context_iterate"
#34 0xb7593b67 in IA__g_main_loop_run (loop=0x8179d88) at gmain.c:2881
        got_ownership = -1218211840
        self = (GThread *) 0x80dc688
        __PRETTY_FUNCTION__ = "IA__g_main_loop_run"
#35 0xb7ae6281 in IA__gtk_main () at gtkmain.c:1003
        tmp_list = (GList *) 0x235
        functions = (GList *) 0x0
        init = (GtkInitFunction *) 0x80dcc28
        loop = (GMainLoop *) 0x8179d88
#36 0x08066e85 in main (argc=1, argv=0xbfd8c594) at gedit.c:566
        program = (GnomeProgram *) 0x80dcc28
        context = <value optimized out>
        window = <value optimized out>
        app = <value optimized out>
        restored = <value optimized out>
        __PRETTY_FUNCTION__ = "main"
(gdb)

Message #115 received at 374640@bugs.debian.org (full text, mbox, reply):

From: caleb <caleb@calno.com>

To: Osamu Aoki <osamu@debian.org>

Cc: 374640@bugs.debian.org

Subject: Re: gedit: freeze when XIM is used to input Japanese

Date: Mon, 20 Nov 2006 19:42:07 +0000

Osamu Aoki wrote:
> http://bugs.debian.org/374640  Any comments on this bug?

gcin 1.2.9-1 have no this problem.
I tested gcin with XIM mode under zh_TW and zh_CN locales. Gedit works
fine. Gcin's XIM mode does not support Japanese locale, so I can not
test ja_JP with XIM. Gcin's GTK immodule also works happily with gedit.

Wen-Yen Chuang(caleb)

Message #120 received at 374640@bugs.debian.org (full text, mbox, reply):

From: Loïc Minier <lool@dooz.org>

To: Osamu Aoki <osamu@debian.org>

Cc: 374640@bugs.debian.org

Subject: Re: gedit: freeze when XIM is used to input Japanese

Date: Mon, 20 Nov 2006 14:26:58 +0100

        Hi,

On Mon, Nov 20, 2006, Osamu Aoki wrote:
> Thread 1 (Thread -1225505088 (LWP 6662)):
> #0  0xb78078d8 in XIfEvent () from /usr/lib/libX11.so.6

 IIUC, XIfEvent() is a kind of "infinite loop" to wait for a specific
 event.

> #1  0xb7855c3b in _XimXConf () from /usr/lib/libX11.so.6
> #2  0xb7855232 in _XimFlush () from /usr/lib/libX11.so.6
> #3  0xb78555d3 in _XimRead () from /usr/lib/libX11.so.6
> #4  0xb7847878 in _XimForwardEvent () from /usr/lib/libX11.so.6
> #5  0xb7841828 in _XimRegisterFilter () from /usr/lib/libX11.so.6

 This indicates that the XIfEvent() call happens due to internal logic
 in XIM (XFilterEvent() notices that XIM is enabled, and forwards the
 event).

> #6  0xb7801494 in XFilterEvent () from /usr/lib/libX11.so.6
> #7  0xb63ccaae in gtk_im_context_xim_filter_keypress (context=0x81c2990, event=0x81c8f40) at gtkimcontextxim.c:728

 This is where Gtk forwards an event to the IM, here XIM.  The IM will
 filter the event and XFilterEvent() will return "True" if Gtk should
 stop handling the event (because the IM handled it).

>         xevent = {type = 2, serial = 0, send_event = 0, display = 0x80eb178, window = 48234499, root = 76, subwindow = 48234499, time = 20837946, x = 0, y = 0, x_root = 0, y_root = 0, state = 0, keycode = 50, same_screen = 1}

 This is the actual event, which is a KeyPress XEvent (type = 2), with
 no modifiers pressed (state = 0), and it's probably a left shift
 (keycode = 50), but perhaps you have a different keyboard layout.

 Anyway, this looks like a completely normal stack trace, and the
 program while waiting for libX11 to return from its internal logic.  To
 understand the problem further, you would have to debug what happens in
 scim or in X11.  There is a libx11-6-dbg package which can help
 understand what X11 is waiting for, but since this works for other XIM
 based IMs, I suggest you turn on debugging in SCIM.

   Bye,
-- 
Loïc Minier <lool@dooz.org>
        10 SIN
        20 GO TO ROBOT HELL             -- Temple of Robotology

Message #125 received at 374640@bugs.debian.org (full text, mbox, reply):

From: Osamu Aoki <osamu@debian.org>

To: Loïc Minier <lool@dooz.org>

Cc: 374640@bugs.debian.org

Subject: Re: gedit: freeze when XIM is used to input Japanese

Date: Wed, 22 Nov 2006 00:19:49 +0900

On Mon, Nov 20, 2006 at 02:26:58PM +0100, Loïc Minier wrote:
...
> 
>  Anyway, this looks like a completely normal stack trace, and the
>  program while waiting for libX11 to return from its internal logic.  To
>  understand the problem further, you would have to debug what happens in
>  scim or in X11.  There is a libx11-6-dbg package which can help
>  understand what X11 is waiting for, but since this works for other XIM
>  based IMs, I suggest you turn on debugging in SCIM.

No.  It does not work with UIM and SCIM when used through XIM.  When
they are used with IMMODULE, they work.

It is clearly XIM (thus libx11-6-dbg package is needded to debug.)

Osamu

Message #130 received at 374640@bugs.debian.org (full text, mbox, reply):

From: Osamu Aoki <osamu@debian.org>

To: caleb <caleb@calno.com>

Cc: 374640@bugs.debian.org

Subject: Re: gedit: freeze when XIM is used to input Japanese

Date: Wed, 22 Nov 2006 00:23:43 +0900

Hi,

On Mon, Nov 20, 2006 at 07:42:07PM +0000, caleb wrote:
> Osamu Aoki wrote:
> > http://bugs.debian.org/374640  Any comments on this bug?
> 
> gcin 1.2.9-1 have no this problem.

hmmm..

> I tested gcin with XIM mode under zh_TW and zh_CN locales. Gedit works
> fine. Gcin's XIM mode does not support Japanese locale, so I can not
> test ja_JP with XIM. Gcin's GTK immodule also works happily with gedit.

Your gcin uses IMMODULE instead of XIM as its default input path.

ja_JP encoding is eucJP.  What about ja_JP.UTF-8?

Message #135 received at 374640@bugs.debian.org (full text, mbox, reply):

From: Osamu Aoki <osamu@debian.org>

To: Loïc Minier <lool@dooz.org>

Cc: 374640@bugs.debian.org

Subject: Re: gedit: freeze when XIM is used to input Japanese

Date: Wed, 22 Nov 2006 00:37:05 +0900

FYI:

Muto san said:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=201284
https://bugs.freedesktop.org/show_bug.cgi?id=7869

these looks like intesresing.  He applied these patches but it goes into
がそれっぽいのでパッチ適用して試してみているのですが、
_XimRespSyncReplyのMARK_NEED_SYNC_REPLY(ic)
and and loops for ever.

Time to go to sleep.

Osamu the messengar

Message #140 received at 374640@bugs.debian.org (full text, mbox, reply):

From: Loïc Minier <lool@dooz.org>

To: Osamu Aoki <osamu@debian.org>

Cc: 374640@bugs.debian.org, control@bugs.debian.org, libx11-6@packages.debian.org, libx11@packages.qa.debian.org

Subject: Re: gedit: freeze when XIM is used to input Japanese

Date: Tue, 21 Nov 2006 18:26:00 +0100

[Message part 1 (text/plain, inline)]

# warning, two patches in fact
tags 374640 + patch
reassign 374640 libx11-6
forwarded 374640 https://bugs.freedesktop.org/show_bug.cgi?id=7869
severity 374640 important
stop

On Wed, Nov 22, 2006, Osamu Aoki wrote:
> Muto san said:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=201284
> https://bugs.freedesktop.org/show_bug.cgi?id=7869

 Great!

> these looks like intesresing.  He applied these patches but it goes into
> _XimRespSyncReplyのMARK_NEED_SYNC_REPLY(ic)
> and and loops for ever.

 Which patches did you apply?  Could you please try the attached patches
 which I've extracted from the Fedora SRPM?  One looks the same as the
 freedesktop one, the other one seems to flag events appropriately.

-- 
Loïc Minier <lool@dooz.org>
        10 SIN
        20 GO TO ROBOT HELL             -- Temple of Robotology

[bug-201284.patch (text/plain, attachment)]

[dont-forward-keycode-0.patch (text/plain, attachment)]

Message #153 received at 374640@bugs.debian.org (full text, mbox, reply):

From: Osamu Aoki <osamu@debian.org>

To: Lo?c Minier <lool@dooz.org>

Cc: 374640@bugs.debian.org, libx11-6@packages.debian.org, libx11@packages.qa.debian.org, Kenshi Muto <kmuto@debian.org>

Subject: Re: gedit: freeze when XIM is used to input Japanese

Date: Fri, 24 Nov 2006 22:47:51 +0900

On Tue, Nov 21, 2006 at 06:26:00PM +0100, Lo?c Minier wrote:
...
>  Which patches did you apply?  Could you please try the attached patches
>  which I've extracted from the Fedora SRPM?  One looks the same as the
>  freedesktop one, the other one seems to flag events appropriately.

Goto-san and I tried your patch and it did not fix freeze. I upload GDB
full logs to:

 http://people.debian.org/~osamu/public as gedit-logs.tar.gz

I used LANG=en_US.UTF-8 LD_LIBRARY_PATH=/usr/lib/debug to ensure English
message and debug library.

I am not sure this is really X problem.  gcin (another chinese method)
packager told me that he has no problem with using xim mechanism for
gcin.  He claimed that difference of code base may be a cause.

Also, I found few interesting thing about freeze of gedit with UIM.

 * Starting Japanese input mode via mouse clicks to the toolbar works
   flawlessly.
 * When pressing CAPS LOCK key in gedit, it freezes program too when
   UIM is used.
 * CAPS LOCK keey works fine in gedit on the same machine if I use
   locale where xim is not used (like C).
 * Then I realized, just pressing CTRL or ALT or SHIFT alone in gedit
   freeses gedit.
 * -1 log is with all patches.  -2 log was after reverting to standard
    libx11

Osamu

Message #158 received at 374640@bugs.debian.org (full text, mbox, reply):

From: Osamu Aoki <osamu@debian.org>

To: Lo?c Minier <lool@dooz.org>, 374640@bugs.debian.org, libx11-6@packages.debian.org, libx11@packages.qa.debian.org, Kenshi Muto <kmuto@debian.org>

Subject: Re: gedit: freeze when XIM is used to input Japanese

Date: Fri, 24 Nov 2006 23:02:09 +0900

On Fri, Nov 24, 2006 at 10:47:51PM +0900, Osamu Aoki wrote:
> On Tue, Nov 21, 2006 at 06:26:00PM +0100, Lo?c Minier wrote:
...
>  http://people.debian.org/~osamu/public as gedit-logs.tar.gz

Correct URL:
 http://people.debian.org/~osamu/pub as gedit-logs.tar.gz

Message #163 received at 374640@bugs.debian.org (full text, mbox, reply):

From: Loïc Minier <lool@dooz.org>

To: Osamu Aoki <osamu@debian.org>

Cc: 374640@bugs.debian.org, libx11-6@packages.debian.org, libx11@packages.qa.debian.org, Kenshi Muto <kmuto@debian.org>

Subject: Re: gedit: freeze when XIM is used to input Japanese

Date: Fri, 24 Nov 2006 15:12:20 +0100

On Fri, Nov 24, 2006, Osamu Aoki wrote:
> Goto-san and I tried your patch and it did not fix freeze. I upload GDB
> full logs to:
>  http://people.debian.org/~osamu/public as gedit-logs.tar.gz

 (s/public/pub)

> I used LANG=en_US.UTF-8 LD_LIBRARY_PATH=/usr/lib/debug to ensure English
> message and debug library.

 You tried *both* patches, right?

> I am not sure this is really X problem.  gcin (another chinese method)
> packager told me that he has no problem with using xim mechanism for
> gcin.  He claimed that difference of code base may be a cause.

 Yeah, that's what I suggested as well.

 Perhaps you can try adding debugging print statement to SCIM to log
 what happens on particular Xevent?  I think there's also a X event
 proxy in Debian to snoop what happens in X connections, perhaps it's
 xtrace.

 xspecs might have some information on XIM.

-- 
Loïc Minier <lool@dooz.org>
        10 SIN
        20 GO TO ROBOT HELL             -- Temple of Robotology

Message #168 received at 374640@bugs.debian.org (full text, mbox, reply):

From: Osamu Aoki <osamu@debian.org>

To: Loïc Minier <lool@dooz.org>

Cc: 374640@bugs.debian.org, libx11-6@packages.debian.org, libx11@packages.qa.debian.org, Kenshi Muto <kmuto@debian.org>

Subject: Re: gedit: freeze when XIM is used to input Japanese

Date: Sat, 25 Nov 2006 00:48:30 +0900

On Fri, Nov 24, 2006 at 03:12:20PM +0100, Loïc Minier wrote:
> On Fri, Nov 24, 2006, Osamu Aoki wrote:
> > Goto-san and I tried your patch and it did not fix freeze. I upload GDB
> > full logs to:
> >  http://people.debian.org/~osamu/public as gedit-logs.tar.gz
> 
>  (s/public/pub)
> 
> > I used LANG=en_US.UTF-8 LD_LIBRARY_PATH=/usr/lib/debug to ensure English
> > message and debug library.
> 
>  You tried *both* patches, right?

Yes.  I should have used the plural form.  (Typical Japanese mistake.)

> > I am not sure this is really X problem.  gcin (another chinese method)
> > packager told me that he has no problem with using xim mechanism for
> > gcin.  He claimed that difference of code base may be a cause.
> 
>  Yeah, that's what I suggested as well.
> 
>  Perhaps you can try adding debugging print statement to SCIM to log
>  what happens on particular Xevent?  I think there's also a X event
>  proxy in Debian to snoop what happens in X connections, perhaps it's
>  xtrace.

Well todays test was using UIM. I will do the same with SCIM later.

Message #173 received at 374640@bugs.debian.org (full text, mbox, reply):

From: Osamu Aoki <osamu@debian.org>

To: caleb <caleb@calno.com>

Cc: 374640@bugs.debian.org

Subject: gcin under xim

Date: Sat, 25 Nov 2006 00:49:32 +0900

Hi,

I am trying to solve Bug #374640.

You claimed that gcin can use gedit using XIM as imput method instead of
IMMODULE gcin directly.  So far I can not reproduce it.

On Sun, Nov 19, 2006 at 12:32:53PM +0000, caleb wrote:
> Osamu Aoki wrote:
...
> 
> > I tested GTK IMMODULE.  It looks like working but I do not know how it
> > should work.
> 
> Middle-click gcin's tray icon, then you may select Japanese 
> inputmethod(The second item from the bottom).
> Ctrl+Space will toggle gcin's input window on an off.
> Gcin uses Space as endkey. For example, press "a" "Space" "1" in input 
> window can produce a "あ".
> 
> > It does not seem to work with xim method but anyway, I do not know how
> > it should be tested.
> 
> Gcin's XIM mode only supports zh_TW.*, zh_CN.*, and en_US.UTF-8 
> currently. Its default XIM name is "gcin". It also can auto-detect XIM 
> name, according to XMODIFIERS.

I booted with 

LANG=en_US.UTF-8
GTK_IM_MODULE=xim
XMODIFIERS=@im=gcin

( I used modified im-switch configuration file in ~/.xinput.d/ )

Unless I change imputmethod to use gcin, no tray comes out with
CTRL-SPACE.  So far, I can not get input through gcin under XIM.
(I am using gnome-terminal)

Of course, I can use gcin by switching input method with right clicking
gnome-terminal screen and select gcin as input method.  I think my
system has working gcin.

Osamu

Message #178 received at 374640@bugs.debian.org (full text, mbox, reply):

From: Osamu Aoki <osamu@debian.org>

To: Loïc Minier <lool@dooz.org>

Cc: 374640@bugs.debian.org, libx11-6@packages.debian.org, libx11@packages.qa.debian.org, Kenshi Muto <kmuto@debian.org>, 374640-submitter@bugs.debian.org, Ming Hua <minghua@rice.edu>

Subject: Re: gedit: freeze when XIM is used to input Japanese

Date: Sat, 25 Nov 2006 02:05:57 +0900

Hi,

I thought I got freeze under SCIM(XIM) but now I an not sure.
(My comment on SCIM might have been just explaining what
wanghz@gmail.com reported.)

At least SCIM using XIM as its input mechanism does not freeze gedit now
(using standard libx11-6).  I am quite intrigued.

 BTS URL: http://bugs.debian.org/374640 

CCing original poster who had SCIM experience.

Ming, what is your experience?

On Fri, Nov 24, 2006 at 03:12:20PM +0100, Loïc Minier wrote:
> On Fri, Nov 24, 2006, Osamu Aoki wrote:
> > Goto-san and I tried your patch and it did not fix freeze. I upload GDB
> > full logs to:
> >  http://people.debian.org/~osamu/public as gedit-logs.tar.gz
> 
>  (s/public/pub)

Yep.

> > I used LANG=en_US.UTF-8 LD_LIBRARY_PATH=/usr/lib/debug to ensure English
> > message and debug library.
> 
>  You tried *both* patches, right?

Yes but ... I have been testing only UIM(XIM) recently because I was
prompted by MUTO-san.

> > I am not sure this is really X problem.  gcin (another chinese method)
> > packager told me that he has no problem with using xim mechanism for
> > gcin.  He claimed that difference of code base may be a cause.
> 
>  Yeah, that's what I suggested as well.

Well, gcin is not so intuitive for non-chinese.  So so far I have not
figured out how to use it.

Osamu

Message #186 received at 374640@bugs.debian.org (full text, mbox, reply):

From: "Hongzheng Wang" <wanghz@gmail.com>

To: "Osamu Aoki" <osamu@debian.org>, 374640-quiet@bugs.debian.org

Cc: "Loïc Minier" <lool@dooz.org>, 374640@bugs.debian.org, libx11-6@packages.debian.org, libx11@packages.qa.debian.org, "Kenshi Muto" <kmuto@debian.org>, 374640-submitter@bugs.debian.org, "Ming Hua" <minghua@rice.edu>

Subject: Re: Bug#374640: gedit: freeze when XIM is used to input Japanese

Date: Sat, 25 Nov 2006 02:30:03 +0800

[Message part 1 (text/plain, inline)]

Hi all,

To be honest, I do not know well why my bug report is reassigned and
retitled as freeze when XIM is used to input Japanese text ...

The bug I reported is about the Shift key behavior of SCIM in gedit, and I
did not notice the freezing problem reported by others at all :-)

Maybe is there some misunderstanding ... or, just because these bugs are
about both SCIM and gedit?


Thank you all.

On 11/25/06, Osamu Aoki <osamu@debian.org> wrote:
>
> Hi,
>
> I thought I got freeze under SCIM(XIM) but now I an not sure.
> (My comment on SCIM might have been just explaining what
> wanghz@gmail.com reported.)
>
> At least SCIM using XIM as its input mechanism does not freeze gedit now
> (using standard libx11-6).  I am quite intrigued.
>
> BTS URL: http://bugs.debian.org/374640
>
> CCing original poster who had SCIM experience.
>
> Ming, what is your experience?
>
> On Fri, Nov 24, 2006 at 03:12:20PM +0100, Loïc Minier wrote:
> > On Fri, Nov 24, 2006, Osamu Aoki wrote:
> > > Goto-san and I tried your patch and it did not fix freeze. I upload
> GDB
> > > full logs to:
> > >  http://people.debian.org/~osamu/public as gedit-logs.tar.gz
> >
> >  (s/public/pub)
>
> Yep.
>
> > > I used LANG=en_US.UTF-8 LD_LIBRARY_PATH=/usr/lib/debug to ensure
> English
> > > message and debug library.
> >
> >  You tried *both* patches, right?
>
> Yes but ... I have been testing only UIM(XIM) recently because I was
> prompted by MUTO-san.
>
> > > I am not sure this is really X problem.  gcin (another chinese method)
> > > packager told me that he has no problem with using xim mechanism for
> > > gcin.  He claimed that difference of code base may be a cause.
> >
> >  Yeah, that's what I suggested as well.
>
> Well, gcin is not so intuitive for non-chinese.  So so far I have not
> figured out how to use it.
>
> Osamu
>
>
>


-- 
Hongzheng Wang

[Message part 2 (text/html, inline)]

Message #199 received at 374640@bugs.debian.org (full text, mbox, reply):

From: Osamu Aoki <osamu@debian.org>

To: Hongzheng Wang <wanghz@gmail.com>

Cc: 374640-quiet@bugs.debian.org, Loïc Minier <lool@dooz.org>, 374640@bugs.debian.org, libx11-6@packages.debian.org, libx11@packages.qa.debian.org, Kenshi Muto <kmuto@debian.org>, 374640-submitter@bugs.debian.org, Ming Hua <minghua@rice.edu>

Subject: Re: Bug#374640: gedit: freeze when XIM is used to input Japanese

Date: Sat, 25 Nov 2006 14:32:34 +0900

On Sat, Nov 25, 2006 at 02:30:03AM +0800, Hongzheng Wang wrote:
> Hi all,
> 
> To be honest, I do not know well why my bug report is reassigned and
> retitled as freeze when XIM is used to input Japanese text ...
> 
> The bug I reported is about the Shift key behavior of SCIM in gedit, and I
> did not notice the freezing problem reported by others at all :-)
> 
> Maybe is there some misunderstanding ... or, just because these bugs are
> about both SCIM and gedit?

That may be partly my mistake.

There is something funny going with gedit with XIM tools such as SCIM 
and UIM.

After carefully re-reading, I think there may be 2 separate issues with
gedit which may or may not be related.

I do not see any issues like Mr. Hongzheng Wang reported in my system
now.  I am now switched back to SCIM via XIM.  But, at least,  Mr.
Hongzheng Wang had problem.

I have set up another account with UIM via XIM.  There, gedit freeze is
real.  It freezes with shift key alone.

I do not know if the bug is in 
 * gedit
 * XIM tool sets (UIM and SCIM)
 * libx11

At least bugs exist somewhere there.

Osamu

Message #212 received at 374640@bugs.debian.org (full text, mbox, reply):

From: "Hongzheng Wang" <wanghz@gmail.com>

To: "Osamu Aoki" <osamu@debian.org>

Cc: "Loïc Minier" <lool@dooz.org>, 374640@bugs.debian.org, "Kenshi Muto" <kmuto@debian.org>, "Ming Hua" <minghua@rice.edu>

Subject: Re: Bug#374640: gedit: freeze when XIM is used to input Japanese

Date: Sat, 25 Nov 2006 18:06:22 +0800

[Message part 1 (text/plain, inline)]

Hi,

Thank you, Osamu :-)

SCIM via XIM really behaves abnormally in Gedit now.  I'm using the Chinese
pinyin input method engine, and the Shift key has double functionals: one
for temporarily switching Chinese input mode and English input mode; one for
switching between upper and lower characters when pressing some keys, which
is a normal functional in almost all keyboards.  The problem I encountered
is that the SCIM via XIM cannot distinguish between these two modes: it just
performs the two operations simultaneously.  That is, when I active the
Chinese pinyin input method engine, even I press Shift key and another key
at the same time (for example, I wanna input a @), SCIM will input @ (Shift
key's normal switching functional) and also temporarily switching Chinese
and English.  It is really confusing.  And the problem does not arise when
SCIM does not use XIM.

I'm waiting for the Gedit 2.16.  I hope this strange problem can disappear
when the new version of Gedit comes.

On 11/25/06, Osamu Aoki <osamu@debian.org> wrote:
>
> On Sat, Nov 25, 2006 at 02:30:03AM +0800, Hongzheng Wang wrote:
> > Hi all,
> >
> > To be honest, I do not know well why my bug report is reassigned and
> > retitled as freeze when XIM is used to input Japanese text ...
> >
> > The bug I reported is about the Shift key behavior of SCIM in gedit, and
> I
> > did not notice the freezing problem reported by others at all :-)
> >
> > Maybe is there some misunderstanding ... or, just because these bugs are
> > about both SCIM and gedit?
>
> That may be partly my mistake.
>
> There is something funny going with gedit with XIM tools such as SCIM
> and UIM.
>
> After carefully re-reading, I think there may be 2 separate issues with
> gedit which may or may not be related.
>
> I do not see any issues like Mr. Hongzheng Wang reported in my system
> now.  I am now switched back to SCIM via XIM.  But, at least,  Mr.
> Hongzheng Wang had problem.
>
> I have set up another account with UIM via XIM.  There, gedit freeze is
> real.  It freezes with shift key alone.
>
> I do not know if the bug is in
> * gedit
> * XIM tool sets (UIM and SCIM)
> * libx11
>
> At least bugs exist somewhere there.
>
> Osamu
>
>


-- 
Hongzheng Wang

[Message part 2 (text/html, inline)]

Message #217 received at 374640@bugs.debian.org (full text, mbox, reply):

From: Loïc Minier <lool@dooz.org>

To: Hongzheng Wang <wanghz@gmail.com>

Cc: Osamu Aoki <osamu@debian.org>, 374640@bugs.debian.org, Kenshi Muto <kmuto@debian.org>, Ming Hua <minghua@rice.edu>

Subject: Re: Bug#374640: gedit: freeze when XIM is used to input Japanese

Date: Sat, 25 Nov 2006 11:47:50 +0100

On Sat, Nov 25, 2006, Hongzheng Wang wrote:
> I'm waiting for the Gedit 2.16.  I hope this strange problem can disappear
> when the new version of Gedit comes.

 This is unlikely to change with a newer Gedit.  Gedit uses Gtk (which
 internally uses Gdk) to handle the lowlevel keyboard handling, window
 drawing etc. (i.e. talking to X); it's not directly aware of XIM, Gdk
 is.

-- 
Loïc Minier <lool@dooz.org>
        10 SIN
        20 GO TO ROBOT HELL             -- Temple of Robotology

Message #222 received at 374640@bugs.debian.org (full text, mbox, reply):

From: "Hongzheng Wang" <wanghz@gmail.com>

To: "Loïc Minier" <lool@dooz.org>

Cc: "Osamu Aoki" <osamu@debian.org>, 374640@bugs.debian.org, "Kenshi Muto" <kmuto@debian.org>, "Ming Hua" <minghua@rice.edu>

Subject: Re: Bug#374640: gedit: freeze when XIM is used to input Japanese

Date: Sat, 25 Nov 2006 21:17:26 +0800

[Message part 1 (text/plain, inline)]

But only Gedit has this problem.  Other GTK+ based applications, for
example, nautilus, evolution, gvim and even firefox, works well with SCIM
via both XIM and SCIM.  So, there must be some subtle differences between
Gedit and other GTK+ applications...

On 11/25/06, Loïc Minier <lool@dooz.org> wrote:
>
> On Sat, Nov 25, 2006, Hongzheng Wang wrote:
> > I'm waiting for the Gedit 2.16.  I hope this strange problem can
> disappear
> > when the new version of Gedit comes.
>
> This is unlikely to change with a newer Gedit.  Gedit uses Gtk (which
> internally uses Gdk) to handle the lowlevel keyboard handling, window
> drawing etc. (i.e. talking to X); it's not directly aware of XIM, Gdk
> is.
>
> --
> Loïc Minier <lool@dooz.org>
>         10 SIN
>         20 GO TO ROBOT HELL             -- Temple of Robotology
>



-- 
Hongzheng Wang

[Message part 2 (text/html, inline)]

Message #227 received at 374640@bugs.debian.org (full text, mbox, reply):

From: Osamu Aoki <osamu@debian.org>

To: Hongzheng Wang <wanghz@gmail.com>, Loïc Minier <lool@dooz.org>

Cc: 374640@bugs.debian.org, Kenshi Muto <kmuto@debian.org>, Ming Hua <minghua@rice.edu>

Subject: Re: Bug#374640: gedit: freeze when XIM is used to input Japanese

Date: Sat, 25 Nov 2006 22:54:11 +0900

Hi,

Let's put this bug back to gedit if Loïc Minier agrees.

Here is my thought.

On Sat, Nov 25, 2006 at 06:06:22PM +0800, Hongzheng Wang wrote:
> Hi,
> 
> Thank you, Osamu :-)
> 
> SCIM via XIM really behaves abnormally in Gedit now.  I'm using the Chinese
> pinyin input method engine, and the Shift key has double functionals: one
> for temporarily switching Chinese input mode and English input mode; one for
> switching between upper and lower characters when pressing some keys, which
> is a normal functional in almost all keyboards.  The problem I encountered
> is that the SCIM via XIM cannot distinguish between these two modes: it just
> performs the two operations simultaneously.  That is, when I active the
> Chinese pinyin input method engine, even I press Shift key and another key
> at the same time (for example, I wanna input a @), SCIM will input @ (Shift
> key's normal switching functional) and also temporarily switching Chinese
> and English.  It is really confusing.  And the problem does not arise when
> SCIM does not use XIM.

Hmmm... I used smart pinyin now under my SCIM(via XIM).  

Shift-Pressed -> Shift-Released sequence causes Chinese <--> English
mode change.

Shift-Pressed -> Non-SHIFT-key sequence causes case change of
Non-SHIFT-key character.  (With Caps Lock, it changed to lower)

Interesting mechanism.  I confirmed that gedit has problem but no
problem in gnome-terminal text input.  Launching of some threads in
gedit program breaks this normal input function.

On 11/25/06, Loïc Minier <lool@dooz.org> wrote:
>On Sat, Nov 25, 2006, Hongzheng Wang wrote:
>> I'm waiting for the Gedit 2.16.  I hope this strange problem can 
>> disappear when the new version of Gedit comes.
>
>This is unlikely to change with a newer Gedit.  Gedit uses Gtk (which
>internally uses Gdk) to handle the lowlevel keyboard handling, window
>drawing etc. (i.e. talking to X); it's not directly aware of XIM, Gdk
>is.

I agree with Hongzheng's reply on this： "only Gedit has this problem".
Funny thing only happens with gedit.

UIM(XIM)-anthy system has no problem as long as I avoid using these
keys in gedit.

Although there were some confusion on my part initially, these look like
a related bug in gedit handling/pasing of shift/control/alt key or its
following key event handling with XIM process.

Is there any thread which monitor/eat shift key events in gedit?

Osamu

Message #232 received at 374640@bugs.debian.org (full text, mbox, reply):

From: Loïc Minier <lool@dooz.org>

To: Osamu Aoki <osamu@debian.org>

Cc: Hongzheng Wang <wanghz@gmail.com>, 374640@bugs.debian.org, Kenshi Muto <kmuto@debian.org>, Ming Hua <minghua@rice.edu>

Subject: Re: Bug#374640: gedit: freeze when XIM is used to input Japanese

Date: Sat, 25 Nov 2006 14:59:06 +0100

On Sat, Nov 25, 2006, Osamu Aoki wrote:
> Let's put this bug back to gedit if Loïc Minier agrees.

 No, it's either gtk, or x11, but not gedit.  Perhaps it's only visible
 with gtksourceview or gedit + gtksourceview, but the bug is quite
 certainly not in these packages.  You may reassign to gdk/gtk if you
 like.

 Perhaps the difference in behavior comes from the handling of focus.
 I can imagine some events are not handled by the same widget, or that
 more events are generated in one case than the other, or perhaps in a
 different order.

 Did anyone xtrace the thing?

-- 
Loïc Minier <lool@dooz.org>
        10 SIN
        20 GO TO ROBOT HELL             -- Temple of Robotology

Message #237 received at 374640@bugs.debian.org (full text, mbox, reply):

From: Loïc Minier <lool@dooz.org>

To: Osamu Aoki <osamu@debian.org>

Cc: Hongzheng Wang <wanghz@gmail.com>, 374640@bugs.debian.org, Kenshi Muto <kmuto@debian.org>, Ming Hua <minghua@rice.edu>

Subject: Re: Bug#374640: gedit: freeze when XIM is used to input Japanese

Date: Sat, 25 Nov 2006 15:11:22 +0100

[Message part 1 (text/plain, inline)]

        Hi,

On Sat, Nov 25, 2006, Loïc Minier wrote:
>  Perhaps the difference in behavior comes from the handling of focus.
>  I can imagine some events are not handled by the same widget, or that
>  more events are generated in one case than the other, or perhaps in a
>  different order.

 I grepped the gedit sources, and I noticed some things which are likely
 to expose gdk bugs.

 One of the dangerous things that gedit seems to do is registering a
 callback for key_press_event signals against some widgets.  I can
 imagine this can break things in subtle ways, but it's probably a bug
 in Gdk if it let's you break the XIM communication channel (IMO).

 Either Gdk should let you filter XIM things and only let applications
 filter post-XIM events (i.e. events generated by XIM or events not
 handled by XIM) *or* it should permit you to filter all events in a way
 that will suppress all events forwarded to XIM, or none.

 I'm attaching a xtrace of a gedit run where I pressed and released left
 shift multiple time and pressed alt+f4 to exit.

   Bye,
-- 
Loïc Minier <lool@dooz.org>

[gedit.xtrace.gz (application/octet-stream, attachment)]

Message #242 received at 374640@bugs.debian.org (full text, mbox, reply):

From: Loïc Minier <lool@dooz.org>

To: Osamu Aoki <osamu@debian.org>

Cc: Hongzheng Wang <wanghz@gmail.com>, 374640@bugs.debian.org, Kenshi Muto <kmuto@debian.org>, Ming Hua <minghua@rice.edu>, control@bugs.debian.org

Subject: Re: Bug#374640: gedit: freeze when XIM is used to input Japanese

Date: Sat, 25 Nov 2006 15:20:20 +0100

reassign 374640 gedit
forwarded 374640 http://bugzilla.gnome.org/show_bug.cgi?id=376750
tags 374640 + upstream confirmed patch
stop

        Hi again,

On Sat, Nov 25, 2006, Osamu Aoki wrote:
> Let's put this bug back to gedit if Loïc Minier agrees.

 Well, I suck.  It's really a gedit bug, my apologies.

 Gedit reverses the order in which key press event handlers are called
 *and* might generate events twice.  The upstream bug has a patch, could
 you please check it fixes the problem?

 I still believe Gdk has some serious problems if it lets applications
 send crap to X11, but that's obviously harder to fix.  :-/

   Bye,
-- 
Loïc Minier <lool@dooz.org>
        10 SIN
        20 GO TO ROBOT HELL             -- Temple of Robotology

Message #253 received at 374640@bugs.debian.org (full text, mbox, reply):

From: Osamu Aoki <osamu@debian.org>

To: Loïc Minier <lool@dooz.org>

Cc: Hongzheng Wang <wanghz@gmail.com>, 374640@bugs.debian.org, Kenshi Muto <kmuto@debian.org>, Ming Hua <minghua@rice.edu>, control@bugs.debian.org

Subject: Bug#374640: gedit bug and its fix confirmed

Date: Sun, 26 Nov 2006 01:10:47 +0900

[Message part 1 (text/plain, inline)]

Yes.  The third patch posted in upstream fixed both funny SCIM
(Chinese) and frozed UIM problem.  Just to be sure about which patch, I
attached the patch used here by me for testing.  (There was some offset)

Please upload fixed packege soonish.

>  I still believe Gdk has some serious problems if it lets applications
>  send crap to X11, but that's obviously harder to fix.  :-/

Oh well. It is written in C :-)

Osamu

[gedit-window.c.diff-revised3 (text/plain, attachment)]

Message #258 received at 374640@bugs.debian.org (full text, mbox, reply):

From: Wen-Yen Chuang <caleb@calno.com>

To: Osamu Aoki <osamu@debian.org>

Cc: 374640@bugs.debian.org

Subject: Re: Bug#374640: gedit: freeze when XIM is used to input Japanese

Date: Sun, 26 Nov 2006 00:53:37 +0000

Osamu Aoki wrote:
> ( I used modified im-switch configuration file in ~/.xinput.d/ )
export LC_CTYPE=en_US.UTF-8
export XMODIFIERS=@im=gcin
export GTK_IM_MODULE=xim
gcin &
gedit &

It works well in my Sid desktop. Gcin's postinst script does not create
en_US in /etc/X11/xinit/xinput.d. I think that is why im-switch failed
to boot gcin in en_US.UTF-8.

Gcin's XIM mode supports en_US.UTF-8, but not en_US.ISO-8859-1, so I did
not set it for im-switch. Gcin's XIM mode supports all zh_TW.* and all
zh_CN.*, so I set them for im-switch.

About Bug #374640, Loïc Minier has mentioned gedit's problem:
Gedit often passes some "key press event", which will grab by XIM
server. And sometimes XIM server also passes some key press event, which
will grab by gedit.

a user pressed a key -> XIM server get it -> XIM server passes the key
to gedit -> gedit get the key -> gedit passes the key to XIM server ->
and so on...

I know another XIM server(oxim, a fork of xcin) has this problem with gedit.

IMdkit of scim, xcin, and oxim are almost the same. Gcin uses a quite
different IMdkit. I guess that is why gcin is not involved in the gedit
bug. However, I am not a programer. That is just my guess.

Message #263 received at 374640-close@bugs.debian.org (full text, mbox, reply):

From: Loic Minier <lool@dooz.org>

To: 374640-close@bugs.debian.org

Subject: Bug#374640: fixed in gedit 2.14.4-3

Date: Sat, 25 Nov 2006 17:17:09 +0000

Source: gedit
Source-Version: 2.14.4-3

We believe that the bug you reported is fixed in the latest version of
gedit, which is due to be installed in the Debian FTP archive:

gedit-common_2.14.4-3_all.deb
  to pool/main/g/gedit/gedit-common_2.14.4-3_all.deb
gedit-dev_2.14.4-3_all.deb
  to pool/main/g/gedit/gedit-dev_2.14.4-3_all.deb
gedit_2.14.4-3.diff.gz
  to pool/main/g/gedit/gedit_2.14.4-3.diff.gz
gedit_2.14.4-3.dsc
  to pool/main/g/gedit/gedit_2.14.4-3.dsc
gedit_2.14.4-3_i386.deb
  to pool/main/g/gedit/gedit_2.14.4-3_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 374640@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Loic Minier <lool@dooz.org> (supplier of updated gedit package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sat, 25 Nov 2006 17:41:27 +0100
Source: gedit
Binary: gedit-dev gedit-common gedit
Architecture: source i386 all
Version: 2.14.4-3
Distribution: unstable
Urgency: medium
Maintainer: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Changed-By: Loic Minier <lool@dooz.org>
Description: 
 gedit      - official text editor of the GNOME desktop environment
 gedit-common - official text editor of the GNOME desktop environment (support fi
 gedit-dev  - official text editor of the GNOME desktop environment (developmen
Closes: 374640
Changes: 
 gedit (2.14.4-3) unstable; urgency=medium
 .
   [ Josselin Mouette ]
   * Require gnome-pkg-tools 0.6.
   * Use ${gnome:Version} and ${gnome:NextVersion}.
   * Include the gnome-versions.mk snippet.
 .
   [ Loic Minier ]
   * Change description to be "official text editor of the GNOME desktop
     environment" instead of "light-weight text editor"; thanks Tshepang
     Lekhonkhobe.
   * New patch, 10_double-key-events-breaks-xim, to fix double sending of
     keypress X events which broke XIM; from GNOME #376750; closes: #374640.
Files: 
 6a790152eb66a7c8e04722ae51289eb4 1831 gnome optional gedit_2.14.4-3.dsc
 d4664d3b4af4534c0093e863cc152888 179427 gnome optional gedit_2.14.4-3.diff.gz
 ae828ea76c91da9f566afa320c82d6c9 2834202 gnome optional gedit-common_2.14.4-3_all.deb
 3c520262044b35b2db220e9f4ce47e69 47786 devel optional gedit-dev_2.14.4-3_all.deb
 89d746798c29bb9ded50b2a5a687f59a 615426 gnome optional gedit_2.14.4-3_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFaHOQ4VUX8isJIMARApiUAKCPuaGHU8l5Jy21/M2g3TvwP/QtrwCgsqjy
SqMuU7Ec//2K9tbxN8ynoNg=
=QXpx
-----END PGP SIGNATURE-----

Message #268 received at 374640@bugs.debian.org (full text, mbox, reply):

From: Osamu Aoki <osamu@debian.org>

To: Wen-Yen Chuang <caleb@calno.com>

Cc: 374640@bugs.debian.org

Subject: Re: Bug#374640: gedit: freeze when XIM is used to input Japanese

Date: Sun, 26 Nov 2006 03:39:43 +0900

On Sun, Nov 26, 2006 at 12:53:37AM +0000, Wen-Yen Chuang wrote:
> Osamu Aoki wrote:
> >( I used modified im-switch configuration file in ~/.xinput.d/ )
> export LC_CTYPE=en_US.UTF-8
> export XMODIFIERS=@im=gcin
> export GTK_IM_MODULE=xim
> gcin &
> gedit &
> 
> It works well in my Sid desktop. 

Sure.

> Gcin's postinst script does not create
> en_US in /etc/X11/xinit/xinput.d. I think that is why im-switch failed
> to boot gcin in en_US.UTF-8.

Well, close but not quite.  Please apply patch supplied to gcin package
BTS.

> Gcin's XIM mode supports en_US.UTF-8, but not en_US.ISO-8859-1, so I did
> not set it for im-switch. Gcin's XIM mode supports all zh_TW.* and all
> zh_CN.*, so I set them for im-switch.

Basically, im-switch is for the locale which support characters input
through XIM. It is not designed to prevent people to do stupid thing.

Osamu

Message #273 received at 374640@bugs.debian.org (full text, mbox, reply):

From: Ming Hua <minghua@rice.edu>

To: Osamu Aoki <osamu@debian.org>

Cc: 374640@bugs.debian.org, Kenshi Muto <kmuto@debian.org>, 374640-submitter@bugs.debian.org

Subject: Re: gedit: freeze when XIM is used to input Japanese

Date: Mon, 27 Nov 2006 21:30:39 -0600

On Sat, Nov 25, 2006 at 02:05:57AM +0900, Osamu Aoki wrote:
[quotes reordered]
> 
>  BTS URL: http://bugs.debian.org/374640 

Oh my.  This bug report is becoming so convoluted with different issues.
We had better clone it and keep different discussions separated.

> Ming, what is your experience?

I've just done some limited testing.  I'll report what I have and what I
think, more tests will follow.

Currently my test is done in testing environment, with scim 1.4.4-5 and
gedit 2.14.4-2.

I can confirm the results of original reporter of 374640, i.e., strange
behavior of shift key.  Acoording to Loïc's analysis this should be a
gedit bug and already fixed.

> I thought I got freeze under SCIM(XIM) but now I an not sure.
> 
> At least SCIM using XIM as its input mechanism does not freeze gedit now
> (using standard libx11-6).  I am quite intrigued.

I can also get the input freeze in gedit with scim in XIM mode.
Although the freeze deosn't seem to be hard freeze and can be solved by
switching focus out of gedit and back again.  However, I don't think
this is the same bug as the one in gedit, the gedit bug merely triggered
a deeper bug in libX11.

As pointed out by Osamu, there is a Redhat bug [1] investigating this
"lockup-with-XIM-mode" issue, and there is also a reproducer testcase
attached in that report.  That report also points out a workground as
setting "/FrontEnd/X11/Dynamic = true" in ~/.scim/config (this should be
the default in Debian).

I reproduced the freeze with "/FrontEnd/X11/Dynamic = false", so the
freeze observed by Osamu and other Japanese people using UIM is probably
the same thing.  I'll test with "/FrontEnd/X11/Dynamic = true" again
later.

There is also a Ubuntu bug report [2] on a similar freeze issue in
gnome-terminal, and the reporter confirms that workaround works.  I've
also heard about this freeze happening in gaim.

However I don't quite understand the whole discussion in the Redhat bug
report, and there is no patch attached there.  So I don't know what (if
any) is really wrong about libX11.

1. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=201284
2. https://bugs.launchpad.net/distros/ubuntu/+source/scim/+bug/66104

Ming
2006.11.27

Message #281 received at 374640@bugs.debian.org (full text, mbox, reply):

From: Ming Hua <minghua@rice.edu>

To: 374640@bugs.debian.org

Cc: Osamu Aoki <osamu@debian.org>, Kenshi Muto <kmuto@debian.org>

Subject: Re: gedit: freeze when XIM is used to input Japanese

Date: Mon, 27 Nov 2006 23:12:48 -0600

On Mon, Nov 27, 2006 at 09:30:39PM -0600, Ming Hua wrote:
> 
> I've just done some limited testing.  I'll report what I have and what I
> think, more tests will follow.
> 
> Currently my test is done in testing environment, with scim 1.4.4-5 and
> gedit 2.14.4-2.

Tested in unstable environment again.

> I can confirm the results of original reporter of 374640, i.e., strange
> behavior of shift key.  Acoording to Loïc's analysis this should be a
> gedit bug and already fixed.

Got both "funny shift key behavior" and "random freeze" with gedit
2.14.4-2.  Both problems are solved by gedit 2.14.4-3.

Thanks Loïc for tracking down and fixing this bug.

> I can also get the input freeze in gedit with scim in XIM mode.
> Although the freeze deosn't seem to be hard freeze and can be solved by
> switching focus out of gedit and back again.  However, I don't think
> this is the same bug as the one in gedit, the gedit bug merely triggered
> a deeper bug in libX11.
> 
> As pointed out by Osamu, there is a Redhat bug [1] investigating this
> "lockup-with-XIM-mode" issue, and there is also a reproducer testcase
> attached in that report.  That report also points out a workground as
> setting "/FrontEnd/X11/Dynamic = true" in ~/.scim/config (this should be
> the default in Debian).
> 
> I reproduced the freeze with "/FrontEnd/X11/Dynamic = false", so the
> freeze observed by Osamu and other Japanese people using UIM is probably
> the same thing.  I'll test with "/FrontEnd/X11/Dynamic = true" again
> later.

Tested with "/FrontEnd/X11/Dynamic = true" again, and still can
reproduce the freeze with old gedit (but can't reproduce with new
gedit).  So I was wrong, this freeze issue is irrelevant to the Redhat
bug.

> 1. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=201284

Ming
2006.11.27

Message #286 received at 374640@bugs.debian.org (full text, mbox, reply):

From: "Etsushi Kato" <ek.kato@gmail.com>

To: 374640@bugs.debian.org

Subject: lool@dooz.org

Date: Tue, 28 Nov 2006 20:48:26 +0900

Hi,

I'm a reporter of the GNOME bug #376750
(http://bugzilla.gnome.org/show_bug.cgi?id=376750) and the solution in
redhat bug # 201284 and freedesktop bug #7606 is totally bogus.  It is
not a bug in libX11 and that should be an another bug to be solved in
IMdKit.

And, the debian bug  374640 is a bug in gedit's event handling and
already solved with paolo borelli's patch (comment #14 in GNOME bug
#376750).

Loïc, could you use paolo's patch instead of my patch?  Practically my
patch works fine without any problem, but theoretically paolo's one is
better.

Cheers,
-- 
Etsushi Kato
ek.kato@gmail.com

Message #291 received at 374640@bugs.debian.org (full text, mbox, reply):

From: "Etsushi Kato" <ek.kato@gmail.com>

To: 374640@bugs.debian.org

Cc: lool@dooz.org

Subject: Re: gedit: freeze when XIM is used to input Japanese

Date: Tue, 28 Nov 2006 21:18:10 +0900

Loïc,

I'm sorry, I didn't intended to put your address in the Subject for
the bug report.  I've just wanted to add you to Cc.

Regards,
-- 
Etsushi Kato
ek.kato@gmail.com

Message #296 received at 374640@bugs.debian.org (full text, mbox, reply):

From: Loïc Minier <lool@dooz.org>

To: Etsushi Kato <ek.kato@gmail.com>

Cc: 374640@bugs.debian.org

Subject: Re: lool@dooz.org

Date: Tue, 28 Nov 2006 14:05:42 +0100

On Tue, Nov 28, 2006, Etsushi Kato wrote:
> Loïc, could you use paolo's patch instead of my patch?  Practically my
> patch works fine without any problem, but theoretically paolo's one is
> better.

 Yes, I planned updating the patch, but I was waiting:
 1) for the upstream bug to settle down (final patch committed)
 2) for a fixed gedit to transition to testing, which just happened

 If you like, you can ping me again when the upstream bug closes, in
 case I miss it.

-- 
Loïc Minier <lool@dooz.org>
  "You see, killbots have a preset kill limit.  Knowing their weakness,
   I sent wave after wave of my own men at them until they reached their
   limit and shutdown."                                -- Zapp Brannigan

Message #301 received at 374640@bugs.debian.org (full text, mbox, reply):

From: "Etsushi Kato" <ek.kato@gmail.com>

To: "Loïc Minier" <lool@dooz.org>

Cc: 374640@bugs.debian.org

Subject: Re: gedit: freeze when XIM is used to input Japanese

Date: Tue, 28 Nov 2006 23:16:39 +0900

On 11/28/06, Loïc Minier <lool@dooz.org> wrote:
> On Tue, Nov 28, 2006, Etsushi Kato wrote:
> > Loïc, could you use paolo's patch instead of my patch?  Practically my
> > patch works fine without any problem, but theoretically paolo's one is
> > better.
>
>  Yes, I planned updating the patch, but I was waiting:
>  1) for the upstream bug to settle down (final patch committed)
>  2) for a fixed gedit to transition to testing, which just happened

Tha's fine.  I'm also waiting for 1).

>  If you like, you can ping me again when the upstream bug closes, in
>  case I miss it.

OK.

Thanks,
-- 
Etsushi Kato
ek.kato@gmail.com

Message #306 received at 374640-close@bugs.debian.org (full text, mbox, reply):

From: Loic Minier <lool@dooz.org>

To: 374640-close@bugs.debian.org

Subject: Bug#374640: fixed in gedit 2.14.4-4

Date: Sun, 03 Dec 2006 12:47:06 +0000

Source: gedit
Source-Version: 2.14.4-4

We believe that the bug you reported is fixed in the latest version of
gedit, which is due to be installed in the Debian FTP archive:

gedit-common_2.14.4-4_all.deb
  to pool/main/g/gedit/gedit-common_2.14.4-4_all.deb
gedit-dev_2.14.4-4_all.deb
  to pool/main/g/gedit/gedit-dev_2.14.4-4_all.deb
gedit_2.14.4-4.diff.gz
  to pool/main/g/gedit/gedit_2.14.4-4.diff.gz
gedit_2.14.4-4.dsc
  to pool/main/g/gedit/gedit_2.14.4-4.dsc
gedit_2.14.4-4_i386.deb
  to pool/main/g/gedit/gedit_2.14.4-4_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 374640@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Loic Minier <lool@dooz.org> (supplier of updated gedit package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sun,  3 Dec 2006 13:20:33 +0100
Source: gedit
Binary: gedit-dev gedit-common gedit
Architecture: source i386 all
Version: 2.14.4-4
Distribution: unstable
Urgency: low
Maintainer: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Changed-By: Loic Minier <lool@dooz.org>
Description: 
 gedit      - official text editor of the GNOME desktop environment
 gedit-common - official text editor of the GNOME desktop environment (support fi
 gedit-dev  - official text editor of the GNOME desktop environment (developmen
Closes: 374640
Changes: 
 gedit (2.14.4-4) unstable; urgency=low
 .
   * Update patch 10_double-key-events-breaks-xim with the final upstream fix;
     closes: #374640.
Files: 
 6928915f8952fc8b1b7df856abd185c4 1831 gnome optional gedit_2.14.4-4.dsc
 fb3a08305cc332d20f22ad0c8846fa3c 162328 gnome optional gedit_2.14.4-4.diff.gz
 160519ade6510fbcd66e2f1567378e5b 2834124 gnome optional gedit-common_2.14.4-4_all.deb
 48ec7a49b5445c5ccb56edd1faaa55aa 47832 devel optional gedit-dev_2.14.4-4_all.deb
 02960ccc892923d4f6651fc25bb6d6ee 615500 gnome optional gedit_2.14.4-4_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFcsWB4VUX8isJIMARAlXlAJ4pLMSD3h6LlS1GVi/tqldEAnmFhwCguuA6
atHAXO4LXMUu6JRmuRd49rk=
=baM1
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.