From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Hin-Tak Leung Newsgroups: gmane.emacs.help,gmane.emacs.bugs Subject: Re: emacs-19.34 segfaults when built with Xfree 4.3.0(glibc2.3.x,gcc 3.2) Date: Mon, 12 May 2003 23:11:46 +0100 Sender: help-gnu-emacs-bounces+gnu-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: <3EC01C22.3070800@yahoo.co.uk> References: <3EBFB256.4000504@yahoo.co.uk> <3EBFC7DE.1000502@yahoo.co.uk> <3EBFDF38.3050201@yahoo.co.uk> <3EBFEF68.6050202@yahoo.co.uk> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1052777276 31899 80.91.224.249 (12 May 2003 22:07:56 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 12 May 2003 22:07:56 +0000 (UTC) Cc: samuel@ma.hw.ac.uk Original-X-From: help-gnu-emacs-bounces+gnu-help-gnu-emacs=m.gmane.org@gnu.org Tue May 13 00:07:54 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19FLRU-0008CX-00 for ; Tue, 13 May 2003 00:06:45 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 19FLRw-000731-03 for gnu-help-gnu-emacs@m.gmane.org; Mon, 12 May 2003 18:07:12 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 19FLRc-00072p-00 for help-gnu-emacs@gnu.org; Mon, 12 May 2003 18:06:53 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 19FLRb-00072E-00 for help-gnu-emacs@gnu.org; Mon, 12 May 2003 18:06:52 -0400 Original-Received: from smtp016.mail.yahoo.com ([216.136.174.113]) by monty-python.gnu.org with smtp (Exim 4.10.13) id 19FLRa-00071Y-00 for help-gnu-emacs@gnu.org; Mon, 12 May 2003 18:06:50 -0400 Original-Received: from m26-mp1.cvx1-a.cam.dial.ntli.net (HELO yahoo.co.uk) (hintak?leung@62.253.144.26 with plain) by smtp.mail.vip.sc5.yahoo.com with SMTP; 12 May 2003 22:06:44 -0000 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en, en-us Original-To: Thien-Thi Nguyen In-Reply-To: Original-cc: bug-gnu-emacs@gnu.org Original-cc: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: help-gnu-emacs-bounces+gnu-help-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.help:9631 gmane.emacs.bugs:5032 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:9631 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 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 >