Bug 183643

Created attachment 125532 [details]
crash report

Created attachment 125533 [details]
crash report

Same here, but I get the crash composing e-mail with gnus.  Here's a (probably
useless) stack trace:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000544195 in sys_re_search_2 ()
(gdb) where
#0  0x0000000000544195 in sys_re_search_2 ()
#1  0x0000000000544493 in sys_re_search ()
#2  0x0000000000548afc in fast_string_match ()
#3  0x0000000000573826 in vars_of_objects_x ()
#4  0x0000000000574e8d in allocate_nearest_color ()
#5  0x000000000051da2f in Fmake_font_instance ()
#6  0x000000000047d4cb in call_with_suspended_errors ()
#7  0x0000000000479fce in internal_catch ()
#8  0x000000000047d1f1 in call_with_suspended_errors ()
#9  0x000000000054f03f in Fspecifier_fallback ()
#10 0x000000000054f340 in specifier_instance ()
#11 0x000000000054f966 in specifier_instance_no_quit ()
#12 0x00000000004d0268 in face_property_matching_instance ()
#13 0x00000000004d03d7 in ensure_face_cachel_contains_charset ()
#14 0x00000000004d0490 in ensure_face_cachel_contains_charset ()
#15 0x0000000000527d58 in get_display_block_from_line ()
#16 0x0000000000528180 in get_display_block_from_line ()
#17 0x000000000052d7ea in redisplay_frame_text_width_string ()
#18 0x000000000052ffd7 in generate_displayable_area ()
#19 0x00000000005310a6 in generate_displayable_area ()
#20 0x00000000005343b6 in point_at_center ()
#21 0x0000000000535335 in redisplay_frame ()
#22 0x0000000000535846 in Fredraw_frame ()
---Type <return> to continue, or q <return> to quit---
#23 0x0000000000535d1a in redisplay ()
#24 0x00000000004c280d in Fnext_event ()
#25 0x0000000000460335 in Fcommand_loop_1 ()
#26 0x000000000047d646 in condition_case_1 ()
#27 0x0000000000460580 in Frecursive_edit ()
#28 0x0000000000479fce in internal_catch ()
#29 0x000000000046091c in initial_command_loop ()
#30 0x0000000000476c6f in xemacs_21_4_19_x86_64_redhat_linux ()
#31 0x00000000004779cc in main ()

Created attachment 125555 [details]
better backtrace

Reproduced, and better backtrace attached.  It happens here with just M-x
manual-entry rpm and then hitting PgDown a couple of times, no need to isearch.


I guess this is somehow linked with bug 180284.  Running without UTF-8 (LANG=C
xemacs [...]) avoids the crash here.

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

Hmm, xemacs-21.4.18-2.fc5 doesn't seem to crash for me,
but 21.4.19-2.fc5 does at startup for ja_JP.UTF-8.

Curious.  Does 21.4.19-2.fc5 crash for you with -q -vanilla etc as well in that
environment?

Not only does 21.4.19-2.fc5 using "LANG=ja_JP.UTF-8" _not_ crash for me on
startup nor with "M-x manual-entry RET netstat RET", it starts up much snappier
than with en_US.UTF-8 and does not emit any "Missing charsets in String to
FontSet conversion" warnings at startup.

On the other hand, 21.4.18-2.fc5 doesn't crash either here with the same tests,
and it appears to additionally avoid the crash with en_US.UTF-8 and the various
man page test cases listed here.

I suspect something is wrong with compiling XEmacs with gcc 4.1.0. 
21.4.18-2.fc5 was built with gcc 4.0.2, 21.4.19-2.fc5 with 4.1.0.  Will test
build 21.4.18 with gcc 4.1.0 locally next.

Local rebuild of 21.4.18-2.fc5 with gcc 4.1.0 crashes the same way as
21.4.19-2.fc5, so the hunch about this being triggered by the new compiler
appears correct.

Interesting.  CC'ing Jakub.

I found that stripping -fstack-protector from CFLAGS (still with gcc 4.1.0-3)
results in binary that does not crash with the M-x man reproducers from comments
1, 4 and 7.  Will probably do that for now so we can have a less crashy XEmacs
in FE5 from the start.

21.4.19-3 is built without -fstack-protector, leaving open in order to track a
real fix.

21.4.19-3 doesn't crash, but it gets into infinite loops for me in identical
scenarios to the one I had hit when I added comment #3.  I guess there's some
other bug that hits with GCC 4.1, that happens to trigger different behavior
depending on whether -fstack-protector is on or off.

With xemacs-21.4.19-3.fc5.x86_64 I'm seeing basically the same backtrace as in
comment 3 when I run "LANG=ja_JP.UTF-8 xemacs -q", but it doesn't happen with
"LANG=ja_JP.UTF-8 xemacs -vanilla", nor in other locale AFAICT.

I'm seeing infinite loops (hangs) regularly in xemacs (21.4.19-3.fc5 x64) using gnus, too.  It happens 
when I'm reading (mail) as well as composing.  So far I can't reproduce the hangs, but if it will help, I'll try.

I can't reproduce comment 13, nor have I ever really used gnus, so neither much
comments on that either.

I've put a test build of the FE5 xemacs rebuilt with gcc 3.2 online at
http://koti.welho.com/vskytta/xemacs/ , testing welcome.  Non-x86_64 users can
rpmbuild --rebuild the source rpm.

Thanks.  I've installed your rebuilt xemacs, Ville.  So far I've seen no hangs, but since they are 
unpredictable, that won't mean anything until I've been using it a couple of days or so.  If the rebuilt 
version crashes, I'll comment.

Ville, your test package seems to fix the crash at startup for me. :)

21.4.19-4.fc5 built with gcc32 was just pushed towards the repository.  Leaving
this bug open for tracking purposes.

It is no longer crashy, but it is, erhm, freezy.  It quite often stops
responding to keyboard input and repainting the screen, although strace shows it
still gets and responds, in at least some sense, to mouse-in, mouse-out and
repaint events.  I'm afraid I don't have any simple way to trigger this, but it
happens about once a day.  C-g doesn't fix it.  AFAICT the only way out is to
kill xemacs and start over :-(  It does auto-save upon kill (just don't use kill
-9), so it's not *that* bad.  But it is bad.

I haven't got the freezes for quite a while.  Looks like it's fixed.