From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tim X Newsgroups: gmane.emacs.help Subject: Re: Mysterious emacs failure Date: 22 Oct 2005 16:40:28 +1000 Message-ID: <87br1injfn.fsf@tiger.rapttech.com.au> References: Reply-To: timx@spamto.devnul.com NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1129963367 2446 80.91.229.2 (22 Oct 2005 06:42:47 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 22 Oct 2005 06:42:47 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Oct 22 08:42:42 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1ETD5D-0003dT-Cr for geh-help-gnu-emacs@m.gmane.org; Sat, 22 Oct 2005 08:42:23 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ETD5B-0003kI-Ld for geh-help-gnu-emacs@m.gmane.org; Sat, 22 Oct 2005 02:42:22 -0400 Original-Newsgroups: gnu.emacs.help Original-Lines: 68 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 Original-NNTP-Posting-Host: ppp1-92.lns1.syd7.internode.on.net Original-X-Trace: duster.adelaide.on.net 1129963229 59.167.1.92 (22 Oct 2005 16:10:29 +0950) Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!logbridge.uoregon.edu!newsfeeds.ihug.co.nz!ihug.co.nz!news.xtra.co.nz!news-south.connect.com.au!duster.adelaide.on.net!not-for-mail Original-Xref: shelby.stanford.edu gnu.emacs.help:134876 Original-To: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:30461 Archived-At: "Denny Dahl" writes: > Have been hacking at this problem all day and have learned some interesting > things > > but do not have a solution yet.  I was able to successfully start the "bare > impure emacs" > > executable named temacs.  This runs successfully for a few minutes, then it > goes > > nuts attempting (unsuccessfully) to create the directory /.emacs.d over and > over > > again. > >   > > I also built an emacs using "GNU_MALLOC=no ./configure" but this didn't do what > > I expected it to do.  I've been looking through the INSTALL file and > etc/PROBLEMS I think you may be approaching this in the wrong way and don't think you will easily identify the problem by just looking at emacs. Given that 1. Emacs was working fine for sometime 2. Emacs started core dumping after the installation of a new piece of software and a reboot If we assume the new software is the only recent change (i.e. no libraries or other packages have been updated), then its likely something has changed as a result of the new package that was installed. I would - 1. Verify exactly what actions were taken in the installation of the new package. Make sure no libraries or system settings were changed for the new package. 2. Use GDB or some other debugger to inspect the core file and find out at what point the system crashes. 3. Use ldd or similar utility to list the shared libraries used by emacs and the new software. This will verify all shared libraries with the correct versions are still available and possibly identify points of commonality between the two packages. 4. Use something like strace on emacs to get a more precise idea of where the system crashes and what system calls are being processed at that time. The fact you appear to only be getting the problem on the system which has had the new package installed makes it highly likely it is either something directly relating to the installation of that new package or something that was modified in the process by the sys admin who installed the package. Until this is identified, changing configure settings, malloc routines or anything else is really just shooting in the dark - you may get lucky, but the odds are against it. Tim -- Tim Cross The e-mail address on this message is FALSE (obviously!). My real e-mail is to a company in Australia called rapttech and my login is tcross - if you really need to send mail, you should be able to work it out!