Re: emacs-19.34 segfaults when built with Xfree 4.3.0(glibc2.3.x,gcc 3.2)

[Hin-Tak Leung <hintak_leung@yahoo.co.uk>]

Here is the long awaited gdb back trace and strace. It seems to die
at the same place that emacs-21/AIX dies if it is run over a slow
dial-up connection (there were two different patches for that, one of
them by Mr Stallman himself no less, if I remember correctly)
- probably not related. Thought I'd mention this just in case.
==========================
 > gdb emacs-19.34
GNU gdb 5.3
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-slackware-linux"...
(gdb) run
Starting program: /usr/local/bin/emacs-19.34

Program received signal SIGSEGV, Segmentation fault.
0x400908b3 in XtInitializeWidgetClass () from /usr/X11R6/lib/libXt.so.6
(gdb) bt
#0  0x400908b3 in XtInitializeWidgetClass () from /usr/X11R6/lib/libXt.so.6
#1  0x400916a2 in _XtCreateWidget () from /usr/X11R6/lib/libXt.so.6
#2  0x400917c5 in XtCreateWidget () from /usr/X11R6/lib/libXt.so.6
#3  0x08075141 in x_window ()
#4  0x08076228 in Fx_create_frame ()
#5  0x080c65cb in Ffuncall ()
#6  0x080db3f3 in Fbyte_code ()
#7  0x080c6a8a in funcall_lambda ()
#8  0x080c64dc in Ffuncall ()
#9  0x080db3f3 in Fbyte_code ()
#10 0x080c6a8a in funcall_lambda ()
#11 0x080c64dc in Ffuncall ()
#12 0x080db3f3 in Fbyte_code ()
#13 0x080c6a8a in funcall_lambda ()
#14 0x080c64dc in Ffuncall ()
#15 0x080db3f3 in Fbyte_code ()
#16 0x080c6a8a in funcall_lambda ()
#17 0x080c64dc in Ffuncall ()
#18 0x080db3f3 in Fbyte_code ()
#19 0x080c6a8a in funcall_lambda ()
#20 0x080c687e in apply_lambda ()
#21 0x080c5564 in Feval ()
#22 0x0807fa43 in top_level_2 ()
#23 0x080c47ac in internal_condition_case ()
#24 0x0807fa80 in top_level_1 ()
#25 0x080c431b in internal_catch ()
#26 0x0807f9ae in command_loop ()
#27 0x0807f623 in recursive_edit_1 ()
#28 0x0807f6f8 in Frecursive_edit ()
#29 0x0807e5e5 in main ()
#30 0x40240bb4 in __libc_start_main () from /lib/libc.so.6
(gdb)
=================
The last few lines of strace:
=================
open("/usr/X11R6/lib/X11/icons/default/index.theme", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0755, st_size=27, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x401c3000
read(3, "[Icon Theme]\nInherits=core\n", 4096) = 27
close(3)                                = 0
munmap(0x401c3000, 4096)                = 0
--- SIGSEGV (Segmentation fault) ---
rt_sigaction(SIGSEGV, {SIG_DFL}, {0x807dbf0, [], SA_RESTART|0x4000000}, 8) = 0
getpgrp()                               = 11004
ioctl(0, 0x540f, [11004])               = 0
write(2, "Fatal error (11).", 17)       = 17
rt_sigaction(SIGIO, {SIG_IGN}, {0x80845b0, [], SA_RESTART|0x4000000}, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [SEGV 35 43 44 45 46 47 52 53 60 61], [SEGV], 8) = 0
getpid()                                = 11005
kill(11005, SIGSEGV)                    = 0
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
================================

Thien-Thi Nguyen wrote:
> Hin-Tak Leung <hintak_leung@yahoo.co.uk> writes:
> 
>    (Sigh). I would have been a lot happier if one of you had
>    replied with "get me a gdb back strace" than having to digress
>    to lengthy philosphical discussion on reasons to use an
>    older version, or resorting to foul languages.
> 
> although it is encouraging that you know yourself well enough to say
> this, i confess to not feeling comfortable ordering you about like an
> employee.  these lengthy discussions surely would be better replaced by
> some concrete information (as "concrete" as information can be ;-), it
> seems you're saying.  the reasons for using this version (or any version
> for that matter) are not really germaine to debugging the problem, you
> also note.
> 
>    As I said, I would prefer a "yes" or "no" to the gdb debug
>    question. It isn't to difficult to answer either:
>    (1) "possibly, depending on how deep the problem is; can't promise"
>    (2) "Sorry no, no eperience with gdb whatsoever"
> 
> what if some people on the list respond (1) and some people respond
> (2) -- what have you gained and/or lost by this exercise?
> 
>    But you are trying to draw into philosophical discussion again.
>    (I guess that's still better than the "get a f*cking life"
>    or "cheeky f*cker" replies)
> 
> a personal quirk, no doubt: all discussion is philosophical to me, even
> those involving hard bits of free software artifact (both pre- and post-
> core dump ;-).
> 
>    If I had sounded impatient, I had not resort to verbal
>    violence as some others did.
> 
> sometimes the sudden move is easy to interpret as both violent and
> beautiful, and sometimes funny and sometimes sad.  where there is room
> for interpretation there is room for misunderstanding (and bugs!).
> 
> thi
>