Bug 5605 - uim-xim still crashes randomly
Summary: uim-xim still crashes randomly
Status: RESOLVED FIXED
Alias: None
Product: UIM
Classification: Unclassified
Component: libuim (show other bugs)
Version: unspecified
Hardware: SGI IRIX
: high normal
Assignee: uim-bugs
QA Contact:
URL:
Whiteboard:
Keywords:
: 5637 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-01-15 22:20 UTC by Daichi Kawahata
Modified: 2006-06-09 01:21 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Backtrace log (10.71 KB, text/plain)
2006-01-15 22:23 UTC, Daichi Kawahata
Details
Object information (15.42 KB, text/plain)
2006-01-18 02:57 UTC, Daichi Kawahata
Details
Disassemble log for libuim (153.88 KB, application/x-gzip)
2006-01-18 04:09 UTC, Daichi Kawahata
Details
Make log (163.43 KB, text/plain)
2006-01-18 04:13 UTC, Daichi Kawahata
Details
Make log (at rev. 3538) (144.48 KB, text/plain)
2006-06-04 02:53 UTC, Daichi Kawahata
Details
Config log (at rev. 3538) (13.99 KB, text/plain)
2006-06-04 02:56 UTC, Daichi Kawahata
Details

Description Daichi Kawahata 2006-01-15 22:20:53 UTC
Even after 1.0.1 release, it still crashes randomly involving
X applications (kterm etc. they get frozen), I've noticed while
using it, many strange warnings have been logged to my syslog below:

Jan 14 23:50:17 6B:moose Xsession: dick: ERROR: end of file inside list
Jan 14 23:50:17 6B:moose Xsession: dick: 
Jan 14 23:50:17 6B:moose Xsession: dick: *backtrace*
Jan 14 23:50:17 6B:moose Xsession: dick:

I'm not sure how I can get useful backtrace anyway, my g++ is 4.0.1
and cxx flags were "-O2 -g -W -Wall -Wformat=2 -fno-var-tracking"
Comment 1 Daichi Kawahata 2006-01-15 22:23:21 UTC
Created attachment 4353 [details]
Backtrace log

It comes from uim-xim version is 1.1.0 (latest SVN trunk).
Comment 2 Etsushi Kato 2006-01-16 16:38:32 UTC
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,
Comment 3 Etsushi Kato 2006-01-16 19:24:42 UTC
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?
Comment 4 Etsushi Kato 2006-01-16 19:58:44 UTC
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.
Comment 5 Etsushi Kato 2006-01-16 20:23:00 UTC
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().
Comment 6 Daichi Kawahata 2006-01-17 23:50:22 UTC
> It comes from uim-xim version is 1.1.0 (latest SVN trunk).

Not really, it was rev. 2928.
Comment 7 YamaKen 2006-01-18 01:41:32 UTC
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
Comment 8 YamaKen 2006-01-18 01:44:05 UTC
Oops, and these.

- gcc --version

- compile options for the libuim.so
Comment 9 Daichi Kawahata 2006-01-18 02:57:56 UTC
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
Comment 10 Daichi Kawahata 2006-01-18 03:19:14 UTC
> - 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).
Comment 11 YamaKen 2006-01-18 03:29:11 UTC
(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.
Comment 12 Daichi Kawahata 2006-01-18 04:09:50 UTC
Created attachment 4386 [details]
Disassemble log for libuim

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

Here it is.
Comment 13 Daichi Kawahata 2006-01-18 04:13:26 UTC
Created attachment 4387 [details]
Make log

FWIW, I'll upload make log, in which you may find some
harmful warnings.
Comment 14 Etsushi Kato 2006-01-18 13:04:37 UTC
> - 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).

Comment 15 YamaKen 2006-01-24 16:19:56 UTC
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
Comment 16 Daichi Kawahata 2006-01-27 00:27:11 UTC
(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.
Comment 17 Etsushi Kato 2006-02-01 16:11:19 UTC
*** Bug 5637 has been marked as a duplicate of this bug. ***
Comment 18 YamaKen 2006-06-04 01:37:38 UTC
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/
Comment 19 Daichi Kawahata 2006-06-04 02:53:40 UTC
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
Comment 20 Daichi Kawahata 2006-06-04 02:56:10 UTC
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.
Comment 21 Daichi Kawahata 2006-06-04 02:58:49 UTC
GCC is still 4.0.1, GTK+ 2.9.2, GLib 2.11.2.
Comment 22 YamaKen 2006-06-06 18:09:28 UTC
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
Comment 23 Daichi Kawahata 2006-06-07 04:31:40 UTC
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
Comment 24 Daichi Kawahata 2006-06-07 05:16:18 UTC
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.
Comment 25 YamaKen 2006-06-09 01:21:39 UTC
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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.