From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Bob Halley Newsgroups: gmane.emacs.devel Subject: unexelf.c 1.49 causes segfault Date: 17 Sep 2002 03:35:29 -0700 Sender: emacs-devel-admin@gnu.org Message-ID: NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1032259072 23959 127.0.0.1 (17 Sep 2002 10:37:52 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 17 Sep 2002 10:37:52 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17rFjr-0006EJ-00 for ; Tue, 17 Sep 2002 12:37:51 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17rGNd-0006M7-00 for ; Tue, 17 Sep 2002 13:18:57 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17rFk7-00053a-00; Tue, 17 Sep 2002 06:38:07 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17rFi6-0004uA-00 for emacs-devel@gnu.org; Tue, 17 Sep 2002 06:36:02 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17rFha-0004pf-00 for emacs-devel@gnu.org; Tue, 17 Sep 2002 06:36:01 -0400 Original-Received: from woof.play-bow.org ([204.152.186.150]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17rFha-0004pZ-00; Tue, 17 Sep 2002 06:35:30 -0400 Original-Received: by woof.play-bow.org (Postfix, from userid 500) id 54E3D2EB3A; Tue, 17 Sep 2002 03:35:29 -0700 (PDT) Original-To: emacs-pretest-bug@gnu.org Original-Lines: 42 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:7963 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:7963 I'm running RH 7.3 GNU/Linux, with current patches. Kernel is Marcelo 2.4.19. HW is dual athlon 1800 MP. I'm running -current. The change to unexelf.c (revision 1.49) causes emacs to segfault when building it with "make bootstrap": ../src/bootstrap-emacs -batch --no-site-file --multibyte -l autoload --eval '(setq generated-autoload-file "/proj/src/emacs/lisp/loaddefs.el")' -f batch-update-autoloads $wins Directories: /proj/src/emacs/lisp /proj/src/emacs/lisp/calc /proj/src/emacs/lisp/calendar /proj/src/emacs/lisp/emacs-lisp /proj/src/emacs/lisp/emulation /proj/src/emacs/lisp/eshell /proj/src/emacs/lisp/gnus /proj/src/emacs/lisp/international /proj/src/emacs/lisp/language /proj/src/emacs/lisp/mail /proj/src/emacs/lisp/net /proj/src/emacs/lisp/obsolete /proj/src/emacs/lisp/play /proj/src/emacs/lisp/progmodes /proj/src/emacs/lisp/term /proj/src/emacs/lisp/textmodes /proj/src/emacs/lisp/toolbar make[1]: *** [autoloads] Error 139 make[1]: Leaving directory `/proj/src/emacs/lisp' make: *** [bootstrap] Error 2 Investigation with gdb shows the segfault occurring when emacs tries to strncmp (*p, "MALLOC_CHECK_=", 14) == 0) inside of malloc_initialize_hook(). Everythings looks OK before the call to strncmp, and 'p' is valid, but as soon as it is called it segfaults and the stack frame is trashed (or weird): (gdb) where #0 0x40014852 in _r_debug () from /usr/X11R6/lib/libXaw3d.so.7 #1 0x080d364b in malloc_initialize_hook () at emacs.c:707 #2 0x420799ba in ptmalloc_init () from /lib/i686/libc.so.6 #3 0x4207dfa4 in malloc_hook_ini () from /lib/i686/libc.so.6 #4 0x4207a0ad in malloc () from /lib/i686/libc.so.6 #5 0x421156bb in __register_frame () from /lib/i686/libc.so.6 #6 0x4201740a in __libc_global_ctors () from /lib/i686/libc.so.6 #7 0x4201748a in init () from /lib/i686/libc.so.6 #8 0x4000b782 in _dl_init_internal () from /lib/ld-linux.so.2 I have no idea what _r_debug() is, or why gdb thinks that is what was called (or why it was called instead of strncmp(), if that is what happened). This happens with RH's gcc (2.96-112), and with gcc 3.2. If I revert the unexelf.c to version 1.48 and then build, everything works OK again. I do not understand enough about ELF to offer suggestions about unexelf.c. /Bob