[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Mysterious emacs failure
From: |
Tim X |
Subject: |
Re: Mysterious emacs failure |
Date: |
22 Oct 2005 16:40:28 +1000 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 |
"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!