1:54 p.m.
Gentlemen:
The attachment pertains to the problem. There is no subsequent core dump.
Thank you for looking into the matter.
Loading /home1/jlp/apps/XEMACS/xemacs-21.4.9/lisp/loaddefs.elc...
Loading site-load...
Finding pointers to doc strings...
Finding pointers to doc strings...done
Dumping under the name xemacs
Testing for Lisp shadows ...
Fatal error (11).
Your files have been auto-saved.
Use `M-x recover-session' to recover them.
If you have access to the PROBLEMS file that came with your
version of XEmacs, please check to see if your crash is described
there, as there may be a workaround available.
Otherwise, please report this bug by running the send-pr
script included with XEmacs, or selecting `Send Bug Report'
from the help menu.
As a last resort send ordinary email to `crashes(a)xemacs.org'.
*MAKE SURE* to include the information in the command
M-x describe-installation.
If at all possible, *please* try to obtain a C stack backtrace;
it will help us immensely in determining what went wrong.
To do this, locate the core file that was produced as a result
of this crash (it's usually called `core' and is located in the
directory in which you started the editor, or maybe in your home
directory), and type
gdb /home1/jlp/apps/XEMACS/xemacs-21.4.9/src/xemacs core
then type `where' when the debugger prompt comes up.
(If you don't have GDB on your system, you might have DBX,
or XDB, or SDB. A similar procedure should work for all of
these. Ask your system administrator if you need more help.)
Lisp backtrace follows:
intern("paths-el-original-news-inews-program")
(let ((origsym ...)) (if (running-temacs-p) (progn ... ...) (and ... ...)))
# bind (value var)
(lambda (var value) (let (...) (if ... ... ...)))(news-inews-program "inews")
funcall((lambda (var value) (let (...) (if ... ... ...))) news-inews-program
"inews")
# bind (l)
(let ((l ...)) (funcall l (quote news-inews-program) (cond ... ... ... ... ...))
(funcall l (quote mh-progs) (cond ... ... ... ... ...)) (funcall l (quote mh-libs) (cond
... ... ... ...)) (funcall l (quote rmail-spool-directory) (cond ... ... ... ... ... ...))
(funcall l (quote sendmail-program) (cond ... ... ... ...)) (funcall l (quote
remote-shell-program) (cond ... ... ... ... ... ... ... ... ... ... ... ... ...)) (funcall
l (quote manual-program) (if ... "/usr/ucb/man"
"/usr/bin/man")) (funcall l (quote directory-abbrev-alist) (when ... ...)))
initialize-xemacs-paths()
normal-top-level()
# (condition-case ... . error)
# (catch top-level ...)
make[1]: *** [xemacs] Segmentation fault
make[1]: *** Deleting file `xemacs'
make[1]: Leaving directory `/home1/jlp/apps/XEMACS/xemacs-21.4.9/src'
make: *** [src] Error 2
7:34 p.m.
Stephen J. Turnbull wrote:
>>>>>"Ville" == Ville Skytt <Ville>
writes:
>>>>>
>>>>>
Ville> On Wed, 2002-10-09 at 15:54, "J.L.P. López de Victoria"
Ville> wrote:
>> The attachment pertains to the problem. There is no subsequent
>> core dump. Thank you for looking into the matter.
Ville> Please try to do a "ulimit -c unlimited" before building,
Also, we absolutely need to see your Installation file. This is
produced by configure and lives in the top directory of the build
tree.
If you are _not_ using the --pdump option to configure, please try
that. The most sensitive part of the X?Emacs build process is the
"unexec" or "dumping" phase, and --pdump ("portable dumper")
is a huge
improvement in robustness with a couple of minor annoyances (a
separate data file for the pre-loaded Lisp, and problems with using
symlinks to access the executable).
Ville> that way you should get a core dump from the build failure.
Ville> RedHat is known to disable core files by default.
Not to mention all sanity. :-(
If they're so damn good that they don't need core files, they shouldn't
have any programs crashing, either.
Ville, do you know of any good URLs where we can investigate the Red
Hat brokkage du jour (specifically in libc and GCC)? Every single Red
Hat release since about 6.2 has broken the XEmacs build.
I tried --pdump and it worked!
The gzipped config.status files are attached, this to keep them from
joining the
message text.
The file config1.status.gz corresponds to the successful build (--pdump);
config2.status.gz belongs to the original croaker. I ran this again to make
sure the failure could be reproduced. Sure enough, it croaked again as noted
before.
Thanks for your swift assistance. I typeset books daily and xemacs is the
editor of choice (I then groff the text). Being forced to work with
unfamiliar
or less than optimal tools is a pain. :-( I updated to RH-8.0 a couple
of days
ago. This was a re-installation, the conventional RH update creates a
Fankenstein of old and new programs if you have installed what RH quaintly
calls ¨third party packages¨. However, yhey do warn you. The second time
off I installed via disk druid being careful to keep my /home partition
intact.
By the way, the symlink to xemacs caused no problems as dumped.
Sorry I cannot help with a good ¨brokkage du jour¨ URL.
Thanks again.
José Luis
10:10 p.m.
On Wed, 2002-10-09 at 15:54, "J.L.P. López de Victoria" wrote:
The attachment pertains to the problem. There is no subsequent core
dump.
Thank you for looking into the matter.
Please try to do a "ulimit -c unlimited" before building, that way you
should get a core dump from the build failure. RedHat is known to
disable core files by default.
Cheers,
--
\/ille Skyttä
ville.skytta at xemacs.org
2:50 a.m.
>>>> "Ville" == Ville Skytt <Ville>
writes:
Ville> On Wed, 2002-10-09 at 15:54, "J.L.P. López de Victoria"
Ville> wrote:
> The attachment pertains to the problem. There is no subsequent
> core dump. Thank you for looking into the matter.
Ville> Please try to do a "ulimit -c unlimited" before building,
Also, we absolutely need to see your Installation file. This is
produced by configure and lives in the top directory of the build
tree.
If you are _not_ using the --pdump option to configure, please try
that. The most sensitive part of the X?Emacs build process is the
"unexec" or "dumping" phase, and --pdump ("portable dumper")
is a huge
improvement in robustness with a couple of minor annoyances (a
separate data file for the pre-loaded Lisp, and problems with using
symlinks to access the executable).
Ville> that way you should get a core dump from the build failure.
Ville> RedHat is known to disable core files by default.
Not to mention all sanity. :-(
If they're so damn good that they don't need core files, they shouldn't
have any programs crashing, either.
Ville, do you know of any good URLs where we can investigate the Red
Hat brokkage du jour (specifically in libc and GCC)? Every single Red
Hat release since about 6.2 has broken the XEmacs build.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
6:56 a.m.
On Thu, 2002-10-10 at 04:50, Stephen J. Turnbull wrote:
Ville, do you know of any good URLs where we can investigate the Red
Hat brokkage du jour (specifically in libc and GCC)?
Hmm, excusez my French, but what are you specifically looking for? A
live system to login or the patches (haven't checked if they apply any)
to these or something else?
--
\/ille Skyttä
ville.skytta at xemacs.org
10:20 a.m.
>>>> "Ville" == Ville Skytt <Ville>
writes:
Ville> On Thu, 2002-10-10 at 04:50, Stephen J. Turnbull wrote:
> Ville, do you know of any good URLs where we can investigate
> the Red Hat brokkage du jour (specifically in libc and GCC)?
Ville> Hmm, excusez my French, but what are you specifically
Ville> looking for? A live system to login or the patches
Ville> (haven't checked if they apply any) to these or something
Ville> else?
ChangeLogs and patches. I'd like to browse the Logs and patches via
the specs files, I guess.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
7875
days inactive
7876
days old
5 comments
3 participants
participants (3)
-
"J.L.P. López de Victoria" -
Stephen J. Turnbull -
Ville Skyttä