Re: Mysterious emacs failure

[Tim X <timx@spamto.devnul.com>]

"Denny Dahl" <ddahl@travelers.com> 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!