Bug 56228 - xemacs-21.4.5-[12].ia64 dump core
Summary: xemacs-21.4.5-[12].ia64 dump core
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: xemacs (Show other bugs)
(Show other bugs)
Version: 1.0
Hardware: ia64 Linux
Target Milestone: ---
Assignee: Trond Eivind Glomsrxd
QA Contact: Aaron Brown
Depends On:
TreeView+ depends on / blocked
Reported: 2001-11-14 09:31 UTC by Jens Petersen
Modified: 2007-04-18 16:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-11-14 16:42:14 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Jens Petersen 2001-11-14 09:31:19 UTC
Description of Problem:
Dumps core at startup.

Version-Release number of selected component (if applicable):
21.4.5-1, 21.4.5-2

How Reproducible:

Steps to Reproduce:
% xemacs
% xemacs -nw

Actual Results:
% xemacs

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@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 /usr/bin/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:

  add-spec-to-specifier(#<natnum-specifier global=0
fallback=#<natnum-specifier global=<unspecified> fallback=(... ...) 0x18e>
0x192> 0 global)
  # bind (resource class name)
  byte-code("..." [type resource locale class name resource-list
x-get-resource nil warn add-spec-to-specifier throw done t specifier] 8)
  # (catch done ...)
  # bind (resource-list locale type specifier)
  x-init-specifier-from-resources(#<natnum-specifier global=0
fallback=#<natnum-specifier global=<unspecified> fallback=(... ...) 0x18e>
0x192> natnum global ("topToolBarHeight" . "TopToolBarHeight"))
  # bind (specifier resname G33492 locale)
  # bind (locale)
  # (unwind-protect ...)
  # (unwind-protect ...)
  make-device(x nil)
  # bind (display)
  # bind (debugger debug-on-error command-line-args-left)
  # (unwind-protect ...)
  # (condition-case ... . error)
  # (catch top-level ...)
Segmentation fault

Expected Results:
No segfault.

Additional Information:

Rebuilding on locally fixes the problem.
Buildroot damage?

Comment 1 Trond Eivind Glomsrxd 2001-11-14 16:42:08 UTC

Comment 2 Trond Eivind Glomsrxd 2002-07-29 19:11:01 UTC
This was fixed a long time ago - need to start closing bugs :).

Note You need to log in before you can comment on or make changes to this bug.