jean-louis.a.leroy(a)fortis.com writes:
> I have run xemacs under truss, hoping to find the location of the
> core file, without success. I have re-read `man core`, still no
> clue. But I'll ask a sysadmin.
>
> I have found a 32 bit gdb and here's the stack trace and register dump:
>
> (gdb) bt
> #0 0x00000000 in ?? ()
> #1 0xfef620fc in XRegisterIMInstantiateCallback () from /usr/lib/libX11.so.4
To work around the crash, try configuring and building with
--with-xim=no.
To help us debug, build XEmacs with CFLAGS="-g -O2" in the environment
and see if you can still get the crash. This ways, we should be able
to oberve the values of the arguments to the various functions. If
so, please post the traceback, again.
The registers are not very helpful to me, as I know little about the
Sun architecture.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
I'm trying out show-wspace.el:
http://www.emacswiki.org/cgi-bin/wiki/show-wspace.el
Sort of works, but I'm getting millions of messages:
Fontifying region...(invalid-function 0)
Strangely, setting debug-on-error doesn't seem to trap the message.
I'm thinking this should be simple to debug. At the end of show-wspace.el
there are several font-lock-add-keywords that I was thinking might be the
cause, but I don't see it (I'm just going from the font-lock-add-keywords
doc, I don't have any experience with this).
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Hello.
Xemacs crashes on me at startup:
x54209:stas0006>ulimit -c unlimited
x54209:stas0006>xemacs
Fatal error (11).
Your files have been auto-saved.
Use `M-x recover-session' to recover them.
Your version of XEmacs was distributed with a PROBLEMS file that may describe
your crash, and with luck a workaround. Please check it first, but do report
the crash anyway. Please report this bug by invoking M-x report-emacs-bug,
or by selecting `Send Bug Report' from the Help menu. If necessary, send
ordinary email to `xemacs-beta(a)xemacs.org'. *MAKE SURE* to include the XEmacs
configuration from M-x describe-installation, or equivalently the file
Installation in the top of the build tree.
*Please* try *hard* to obtain a C stack backtrace; without it, we are unlikely
to be able to analyze the problem. Locate the core file produced as a result
of this crash (often called `core' or `core.<process-id>', and located in
the directory in which you started XEmacs or your home directory), and type
gdb /home/users/x54209/bin/xemacs core
then type `where' at the debugger prompt. No GDB on your system? You may
have DBX, or XDB, or SDB. (Ask your system administrator if you need help.)
If no core file was produced, enable them (often with `ulimit -c unlimited'
in case of future recurrance of the crash.
Lisp backtrace follows:
# (unwind-protect ...)
make-device(x nil)
# bind (display)
make-x-device(nil)
init-x-win()
# bind (debugger debug-on-error command-line-args-left)
command-line()
# (condition-case ... . ((t (byte-code " §" ... 1))))
# bind (error-data)
normal-top-level()
# (condition-case ... . error)
# (catch top-level ...)
Segmentation Fault (core dumped)
No core is produced though:
x54209:stas0006>ls -l core
ls: cannot access core: No such file or directory
Here's the Xemacs version:
x54209:stas0006>xemacs -nw --version
XEmacs 21.4 (patch 21) "Educational Television" [Lucid] (sparc-sun-solaris2.10, Mule) of Thu Feb 21 2008 on stas0006
Oh btw `xemacs -nw` appears to work flawlessly.
X server is WRQ Reflection X 12.0.0 running on Windows XP Professional Version 2002 with Service Pack 2. All other X clients I have tried work without problem.
Here's how I built my Xemacs:
./configure --with-mule --prefix ~ --pdump
make
make install
Here's my OS version:
x54209:stas0006>uname -a
SunOS stas0006 5.10 Generic_118833-24 sun4v sparc SUNW,Sun-Fire-T200 Solaris
Cordially,
Jean-Louis
= = = = = = = = = = = = = = = = = = = = = = = = =
Fortis disclaimer :
http://www.fortis.be/legal/disclaimer.htm
Privacy policy related to banking activities of Fortis:
http://www.fortis.be/legal/privacy_policy.htm
= = = = = = = = = = = = = = = = = = = = = = = = =
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
I really appreciate the efforts of several people in picking out
issues and updating the tracker.
There are some procedural issues I'd like to clarify. Don't worry too
much about "conforming" exactly to procedure, but I would like to make
some suggestions to make the tracker as useful as possible.
(1) An issue should not be closed until you've confirmed that the
issue is documented in the appropriate places. The mailing list
archives do *not* count as documentation!
(2) Missing, incorrect, or hard-to-find documentation *is* a bug in
itself, even if the related behavior is acceptable. Do not close an
issue as "not a bug" simply because somebody explained why it works
that way on the mailing list.
(3) If you find a patch labelled "committed" in the tracker, it's OK
to assign the issue to the committer as committing a patch is a
definite assumption of responsibility. However, by default you should
bump status only as far as "assigned".
(4) Be conservative about updating status. You should only push
status to "committed", "documented", or "closed" if you understand the
issue and any related patches or documentation well enough to have
written them yourself. (That doesn't mean you need to be able to
write it in English!) If you find yourself doing this more than once
or twice, consider nominating yourself for XEmacs Reviewer. (No joke,
we always need more reviewers!)
(5) Keywords are important! Some keywords are workflow-related, the
"has X" and "needs X" keywords in particular. The "has X" keyword
means that such an item has been contributed, typically by the issue's
creator, and needs to be confirmed before committing the change. The
"needs X" keyword means that such an item must be developed and
committed to resolve the issue. The "has X" and "needs X" keywords
are *not* opposites. When a contributed X is verified and committed,
the "has X" keyword should be removed. Similarly, when an X is
developed and committed, the "needs X" keyword should be removed.
Other keywords refer to XEmacs behavior, and are helpful to users in
filtering out issues unrelated to their problem. At present, I've
created the following keywords for general areas of XEmacs behavior:
display, i18n, input/output, motion, performance, search, and
security. Feel free to add more if appropriate, but as mentioned I'd
like to keep the number small for now. Try to keep new keywords at a
pretty high level of generality.
Currently a majority of the keywords are tracker-related; I'm thinking
about how to get them out of your face, but for now please bear with
that.
Thanks again for helping!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
I've always wanted to fix this. Anybody know of reasons why not?
Guido van Rossum writes:
> (*) When is Emacs going to fix the bug where it decides to fold a line
> that's exactly as wide as the window? This 79 business is really
> silly, and had to impose on people using other editors.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Antbody know anything about this?
To get minibuffer/echo-area resizing, you need to enable
resize-minibuffer-mode.
Barry Warsaw writes:
> BTW, while I have you here :). Are you aware of a modeline bug in
> 21.5.28 that's definitely not present in 21.5.27? I've verified this
> on both Ubuntu and OS X. To reproduce: split the window in half, then
> M-x emacs-version RET. The output of emacs-version is more than one
> line, and you see the full output in the echo area. However, when you
> then hit C-g to clear the echo, it returns to a 1-line height
> minibuffer, but the modeline that should be in the center of the
> window has now crept upward by one line. Keep doing it long enough
> and the middle mode line will reach the top of the window.
>
> Where this really bites you is when you're prompted to save a file to
> a path that's bigger than 80 characters long. Do that enough and your
> top window just gets slowly eaten away.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
>
>
> ----- Original Message ----
> From: FKtPp <mxxx@yyy>
> To: Rick Rankin <xxx@yyy>; XEmacs Beta <xxx@yyy>
> Sent: Sunday, February 24, 2008 10:49:05 PM
> Subject: Re: Speedbar now unconditionally requires ezimage
>
> M-x package-get-package-provider <RET> ezimage <RET>
> ==> (cedet-common "1.01")
Ahh, thank you. After all this time, I really should have known about that command.
--Rick
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
The XEmacs issue tracker at http://tracker.xemacs.org/XEmacs/its/ now
is watching the xemacs-beta mailing list. Specifically, if the
Subject header contains either a `report-xemacs-bug' tag that looks
like "[Bug: 21.5-b28]" or a Roundup "[issue]" tag, and is *not* a
reply message, the post will be automatically gated to the tracker.
If you are not using report-xemacs-bug, please use the "[issue]" tag
to attract the tracker's attention.
This is intended to make sure that issues raised on the mailing list
will be filed on the tracker, to record progress and make them
searchable. OTOH, trackers are a horrible place to hold discussions,
so replies are currently not forwarded from the list to the tracker.
Discussions should continue to be held on the xemacs-beta and
xemacs-patches mailing lists. Rather, the tracker is intended to
record concrete progress (see the User Guide in the tracker sidebar):
a developer being assigned, a patch committed, etc.
If appropriate, any experienced user may file an issue by resending an
ordinary post (doesn't have to be your own!) to the mailing list,
adding the Roundup "[issue]" tag to the Subject to get it recorded in
the tracker. I'm not happy with the duplicates this will produce, but
it shouldn't be that frequent, especially as people start to use those
tags on initial posts. Remember you must avoid using reply headers
(RFC 2822 References or In-Reply-To), so a resend or forward mechanism
would be most appropriate. (Please check the tracker after you do
this, and file bugs against the tracker if it mangles the particular
format you used!)
Also, developers may send tracker control messages via the mailing
list, but they also need to avoid using reply headers (RFC 2822
References or In-Reply-To). See the User Guide for information about
how to do this. Remember that you must use a full issue designator,
such as [issue306], to do this.
Suggestions for improving integration of the mailing lists and tracker
while maintaining the discussion vs. progress record distinction are
very welcome. (Discussions of the wisdom of the workflow policy
somewhat less so at this moment: I'm open to change but first I want
to get the thing working!)
Specifically, (1) I wonder how to add xemacs-patches to this workflow.
(2) The mechanism for forwarding a message to the tracker should be
improved.
Regards,
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta