Bug 183643 - XEmacs built with -fstack-protector is crashy
XEmacs built with -fstack-protector is crashy
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xemacs (Show other bugs)
rawhide
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Ville Skyttä
Fedora Extras Quality Assurance
:
: 185140 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-02 09:08 EST by Neal Becker
Modified: 2007-11-30 17:11 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-06-17 14:14:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
crash report (1.90 KB, text/plain)
2006-03-02 09:08 EST, Neal Becker
no flags Details
crash report (2.55 KB, text/plain)
2006-03-02 09:11 EST, Neal Becker
no flags Details
better backtrace (6.57 KB, patch)
2006-03-02 13:58 EST, Ville Skyttä
no flags Details | Diff

  None (edit)
Description Neal Becker 2006-03-02 09:08:52 EST
Description of problem: 
 
Every time I do M-x man rpm, then C-s query-format and hit C-s a couple times 
it crashes. 
 
Version-Release number of selected component (if applicable): 
xemacs-21.4.19-2.fc5 
 
How reproducible: 
 
every time 
Steps to Reproduce: 
1. See above 
2. 
3. 
   
Actual results: 
 
 
Expected results: 
 
 
Additional info:
Comment 1 Neal Becker 2006-03-02 09:08:52 EST
Created attachment 125532 [details]
crash report
Comment 2 Neal Becker 2006-03-02 09:11:37 EST
Created attachment 125533 [details]
crash report
Comment 3 Alexandre Oliva 2006-03-02 09:54:57 EST
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 ()
Comment 4 Ville Skyttä 2006-03-02 13:58:01 EST
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.
Comment 5 Ville Skyttä 2006-03-13 02:14:51 EST
*** Bug 185140 has been marked as a duplicate of this bug. ***
Comment 6 Jens Petersen 2006-03-13 22:00:21 EST
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.
Comment 7 Ville Skyttä 2006-03-14 02:12:14 EST
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.
Comment 8 Ville Skyttä 2006-03-14 02:28:59 EST
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.
Comment 9 Jens Petersen 2006-03-14 02:36:00 EST
Interesting.  CC'ing Jakub.
Comment 10 Ville Skyttä 2006-03-18 16:42:28 EST
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.
Comment 11 Ville Skyttä 2006-03-19 05:22:04 EST
21.4.19-3 is built without -fstack-protector, leaving open in order to track a
real fix.
Comment 12 Alexandre Oliva 2006-03-21 12:04:09 EST
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.
Comment 13 Jens Petersen 2006-03-29 04:06:20 EST
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.
Comment 14 ctm 2006-03-29 11:50:21 EST
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.
Comment 15 Ville Skyttä 2006-03-29 12:35:14 EST
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.
Comment 16 ctm 2006-03-29 13:08:25 EST
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.
Comment 17 Jens Petersen 2006-03-30 03:07:12 EST
Ville, your test package seems to fix the crash at startup for me. :)
Comment 18 Ville Skyttä 2006-04-05 12:11:32 EDT
21.4.19-4.fc5 built with gcc32 was just pushed towards the repository.  Leaving
this bug open for tracking purposes.
Comment 19 Alexandre Oliva 2006-04-11 00:10:46 EDT
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.
Comment 20 Alexandre Oliva 2006-06-17 14:14:23 EDT
I haven't got the freezes for quite a while.  Looks like it's fixed.

Note You need to log in before you can comment on or make changes to this bug.