Bug 5605

Created attachment 4353 [details]
Backtrace log

It comes from uim-xim version is 1.1.0 (latest SVN trunk).

It seems that this crash comes from not uim-xim side but scheme side.

Could you check what is happening while using uim-xim with "LIBUIM_VERBOSE=1
uim-xim"?  It'll show a backtrace of scheme interpreter.  Also could you tell me
which IM do you use?

Thanks,

Oops, I didn't noticed your attached backtrace of uim-xim, sorry.  It helps very
much.

From the log, it seems something is wrong about NLS related in scheme
interpreter.  Could you tell me whether ENABLE_NLS (in config.h) is on or off in
your SGI platform?

Again, I checked your backtrace log, and found NLS is not related to this
problem.  It is related to libuim's GC protect mechanism for GCC4.  I'll
investigate more later.

Add YamaKen to CC.

Could you investigate the problem if you have a free time, YamaKen?
As far as I can tell, something weird occurred between uim_scm_eval_c_string()
and uim_scm_eval_c_string_internal().

> It comes from uim-xim version is 1.1.0 (latest SVN trunk).

Not really, it was rev. 2928.

Thanks for the investigations.

I've taken a look at the backtrace and seen the problem. Please provide
following information to make the problem closer.

- Does the problem also occur when UIM_SCM_GCC4_READY_GC of
  uim-scm.h is set to 0?

- Etsushi, is it ensured that no thread switching occurs while
  uim_scm_eval_c_string() is being executed?

- readelf -h libuim.so

- dump of following functions from 'objdump -d libuim.so'
  uim_scm_eval_c_string
  uim_scm_eval_c_string_internal
  uim_scm_gc_protect_stack_internal
  siod_gc_protect_stack
  uim_scm_gc_unprotect_stack
  siod_gc_unprotect_stack

Oops, and these.

- gcc --version

- compile options for the libuim.so

Created attachment 4383 [details]
Object information

> - Does the problem also occur when UIM_SCM_GCC4_READY_GC of
>   uim-scm.h is set to 0?

Compilation finished, I'll test that with this one.

> - readelf -h libuim.so
>
> - dump of following functions from 'objdump -d libuim.so'
>   uim_scm_eval_c_string
>   uim_scm_eval_c_string_internal
>   uim_scm_gc_protect_stack_internal
>   siod_gc_protect_stack
>   uim_scm_gc_unprotect_stack
>   siod_gc_unprotect_stack

It's a bit large to paste here, instead you can see them
at the uploaded log, a question is, how can I extract
function dumps from the disassemble log? There's no each
functions' section, thus it was took with `-T' option.

> gcc --version

gcc (GCC) 4.0.1, `gcc -v' gives:

Reading specs from /usr/local/lib32/gcc/mips-sgi-irix6.5/4.0.1/specs
Target: mips-sgi-irix6.5
Configured with: ../configure --prefix=/usr/local \
--libdir=/usr/local/lib32 --mandir=/usr/local/share/man \
--disable-shared --disable-multilib --enable-threads \
--enable-version-specific-runtime-libs --enable-libgcj
Thread model: single
gcc version 4.0.1

> - compile options for the libuim.so

CFLAGS/CXXFLAGS were "-O2 -g -W -Wall -Wformat=2 -fno-var-tracking",
options passed to the configure script is:

  --prefix=/usr/local --libdir=/usr/local/lib32 \
  --mandir=/usr/local/share/man --disable-static \
  --enable-dict --with-qt --with-qt-immodule

and I got:

   Anthy           : yes
   Canna           : no
   Mana            : no
   PRIME           : yes
   m17n-lib        : yes
   SCIM            : no
   Gtk+            : yes
   Gnome           : yes
   Gnome Applet    : yes
   Qt              : yes
   Qt immodule     : cannot
   FEP             : yes
   Emacs           : yes
   XIM             : yes
   DICT            : yes
   EB              : yes
   libedit         : yes
   Default toolkit : gtk

at the end of configure (you can ignore Qt blah, my Qt won't
compile with given immodule patch in the first place).

(In reply to comment #9)
> > - dump of following functions from 'objdump -d libuim.so'
> >   uim_scm_eval_c_string
> >   uim_scm_eval_c_string_internal
> >   uim_scm_gc_protect_stack_internal
> >   siod_gc_protect_stack
> >   uim_scm_gc_unprotect_stack
> >   siod_gc_unprotect_stack
> 
> It's a bit large to paste here, instead you can see them
> at the uploaded log, a question is, how can I extract
> function dumps from the disassemble log? There's no each
> functions' section, thus it was took with `-T' option.

Ah, what I want is the disassembled codes. Please upload it.

Created attachment 4386 [details]
Disassemble log for libuim

> Ah, what I want is the disassembled codes. Please upload it.

Here it is.

Created attachment 4387 [details]
Make log

FWIW, I'll upload make log, in which you may find some
harmful warnings.

> - Etsushi, is it ensured that no thread switching occurs while
>   uim_scm_eval_c_string() is being executed?

No switching (uim-xim is single threaded).

I've noticed that the debugging information is likely broken after viewed the
source between uim_scm_eval_c_string() and uim_scm_eval_c_string_internal() with
the corresponding backtrace log.

Please try followings in order if your surplus time allows.

1. Omit "-O2" from both CFLAGS and CXXFLAGS and retry getting the backtrace
2. Upgrade gcc to 4.0.2 and retry
3. install gcc 3.4.5 and retry
4. Omit "-fno-var-tracking" and retry with gcc 4.0.2 and gdb 6.1 or later

(In reply to comment #15)
> I've noticed that the debugging information is likely broken after
> viewed the source between uim_scm_eval_c_string() and
> uim_scm_eval_c_string_internal() with the corresponding backtrace log.

As of revision 2940, there's no crashes on uim-xim, now I'm using
a snapshot version:

  Revision: 2989
  Node Kind: directory
  Schedule: normal
  Last Changed Author: ekato
  Last Changed Rev: 2989
  Last Changed Date: 2006-01-24 21:54:43 +0900 (Tue, 24 Jan 2006)

though it still emits `ERROR: end of file inside read' like error
messages without any useful trace, occasionally.

> Please try followings in order if your surplus time allows.
> 
> 1. Omit "-O2" from both CFLAGS and CXXFLAGS and retry getting the
>    backtrace
> 2. Upgrade gcc to 4.0.2 and retry
> 3. install gcc 3.4.5 and retry
> 4. Omit "-fno-var-tracking" and retry with gcc 4.0.2 and gdb 6.1
>    or later

So I'll try to rebuild following your suggestion when I'll get a
crash. As for the no. 4 the reason I use that flag is, if I omit
it, generated binary with gcc 4.x is impossible to debug with my
gdb 5.3, dbx and problem is gdb 6.1 won't work in my environment
due to lack of signal support.

Etsushi, YamaKen, thank you for your supports, please close this
account or leave it as is, if I'll happen to come across a crash,
will re-open or upload useful stack trace.

*** Bug 5637 has been marked as a duplicate of this bug. ***

In r3536, a critical GC bug has been fixed. Please try r3537 of 1.1 branch or 
upcoming 1.1.0. And please run uim/test-gc also.

http://anonsvn.freedesktop.org/svn/uim/branches/1.1/

Created attachment 5804 [details]
Make log (at rev. 3538)

It gives a compilation error, several warnings.
(To continue a make process, `-i' option enabled.)

FWIW,

$ nm -AD *.so|grep
uim_scm_gc
libuim-custom.so:	  U uim_scm_gc_protect
libuim-custom.so:	  U uim_scm_gc_protect_stack
libuim-custom.so:	  U uim_scm_gc_unprotect_stack
libuim.so:5ffdaaa8 A uim_scm_gc_protect
libuim.so:5ffd9ed8 A uim_scm_gc_protect_stack
libuim.so:5ffd9fd8 A uim_scm_gc_unprotect_stack

Created attachment 5805 [details]
Config log (at rev. 3538)

On a side note, IRIX doesn't have `stdint.h', `inttypes.h' is
the place to define types (via typedefs) with size attributes.

GCC is still 4.0.1, GTK+ 2.9.2, GLib 2.11.2.

Your compilation log indicates that the included uim-scm.h is not the r3538's
but old one, or UIM_SCM_GCC4_READY_GC is locally modified to 0. Please check them.

New libuim compiled with gcc and UIM_SCM_GCC4_READY_GC=1 must show the symbols
as follows.

$ nm -AD libuim.so|grep uim_scm_gc
libuim.so:0001784c T uim_scm_gc_current_stack_internal
libuim.so:0001f024 D uim_scm_gc_current_stack_ptr
libuim.so:000177fc T uim_scm_gc_protect
libuim.so:00017860 T uim_scm_gc_protect_stack_internal
libuim.so:0001f028 D uim_scm_gc_protect_stack_ptr
libuim.so:00017824 T uim_scm_gc_unprotect_stack

Shame on me, you're obviously right, now I'm compiling...

$ svn diff uim/uim-scm.h 
Index: uim/uim-scm.h
===================================================================
--- uim/uim-scm.h       (revision 3594)
+++ uim/uim-scm.h       (working copy)
@@ -59,7 +59,7 @@
 #endif
 
 
-#define UIM_SCM_GCC4_READY_GC 1
+#define UIM_SCM_GCC4_READY_GC 0
 
 /*
   uim companion tools should treat lisp object as opaque. struct

Do you find it valid? Anyway, now compilation has finished,
although uim-xim is no longer crashed, I had been still having
a problem, will report that if I'll happen to see, thanks.

At revision 3594.

$ ./test-gc 
stack growth dir = upwards, protected = 7ffb7de0, actual = 7ffb7de0
stack growth dir = upwards, protected = 7ffb7de0, actual = 7ffb7de0
stack growth dir = upwards, protected = 7ffb7de0, actual = 7ffb7de0
stack growth dir = upwards, protected = 7ffb7de0, actual = 7ffb7de0
stack growth dir = upwards, protected = 7ffb7de0, actual = 7ffb7de0
stack growth dir = upwards, protected = 7ffb7de0, actual = 7ffb7de0
tests succeeded.

The GC protection on the stack looks working correctly. Thanks for testing.

Is your remaining 'problem' a random crash as like as previously happened on
uim-xim? If so, please reopen this, or report as new bug.