Anyone using Oort with XEmacs 21.4.6?

Anyone using Oort with XEmacs 21.4.6?

[Russ Allbery]

I'm getting core dumps when using XEmacs 21.4.6.  I'm likely to just
switch back to 21.1.12 for right now since 21.4.6 also has an annoying
performance regression when deleting text out of a font-lock buffer, but
I'm curious whether anyone else is seeing this one or if it's something
peculiar to my configuration.

It doesn't happen all the time, but about 25-50% of the time when starting
up a new XEmacs and going into Gnus I was getting a core dump.

Here's the Lisp backtrace:

  # bind (form)
  gnus-byte-compile((lambda (file orig-file) (nnmail-split-incoming file (quote nnml-save-mail) (quote nil) (if ... nil ...) (quote nnml-active-number))))
  # bind (source incomings incoming total new i group-in fetching-sources sources spool-func group temp exit-func method)
  nnmail-get-new-mail(nnml nnml-save-nov "~/Mail/" nil)
  # bind (server group)
  nnml-request-scan(nil "")
  # bind (gnus-command-method gnus-inhibit-demon mail-source-plugged gnus-command-method group)
  gnus-request-scan(nil (nnml ""))
  # bind (where mesg force method)
  gnus-read-active-file-1((nnml "") nil)
  # (condition-case ... . ((quit (message "Quit reading the active file"))))
  # (unwind-protect ...)
  # bind (methods method not-native force)
  gnus-read-active-file(nil nil)
  # bind (init nnmail-fetched-sources dont-connect level rawfile)
  gnus-setup-news(nil nil nil)
  byte-code("..." [dont-connect did-connect gnus-group-quit gnus-run-hooks gnus-startup-hook gnus-make-newsrc-file gnus-startup-file gnus-current-startup-file gnus-slave gnus-use-dribble-file gnus-dribble-read-file gnus-use-grouplens bbb-login add-hook gnus-summary-mode-hook gnus-grouplens-mode gnus-setup-news nil level gnus-setup-news-hook gnus-start-draft-setup gnus-group-list-groups gnus-group-first-unread-group gnus-configure-windows group gnus-group-set-mode-line gnus-started-hook] 4)
  # bind (level did-connect slave dont-connect arg)
  gnus-1(nil nil nil)
  # bind (slave dont-connect arg)
  gnus(nil)
  # bind (command-debug-status)
  call-interactively(gnus)
  # (condition-case ... . error)
  # (catch top-level ...)

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: Anyone using Oort with XEmacs 21.4.6?

[Chris Halverson]

Russ Allbery <rra@stanford.edu> writes:

> I'm getting core dumps when using XEmacs 21.4.6.  I'm likely to just
> switch back to 21.1.12 for right now since 21.4.6 also has an annoying
> performance regression when deleting text out of a font-lock buffer, but
> I'm curious whether anyone else is seeing this one or if it's something
> peculiar to my configuration.

I am. I haven't had any problems with it, at least none that I didn't
normally have (Gnus sometimes barfs on messages w/ weird attachments
or something, usually it's junk so I don't worry about it too
much). This is w/ Oort updated probably back in November or so. Sun
SPARC 8. I've used it w/ no problems during the whole 21.4 series.

cdh

-- 
Chris D. Halverson                         Complete Internet Solutions
(612) 279-2106                             http://www.completeis.com/

Re: Anyone using Oort with XEmacs 21.4.6?

[Karl Kleinpaste]

I regularly update to the latest beta or gamma XEmacs, and I keep very
regularly updated in Oort Gnus.  I last updated Oort this morning, and
I'm running 21.4.6 under Linux RH7.1.  No worries, for the most part;
once in a blue moon, I get a coredump, but I have yet to trace it down
to anything identifiable.  That happens perhaps once a week.  I have
never seen a trace like the one you sent.  What's your platform?

Re: Anyone using Oort with XEmacs 21.4.6?

[Russ Allbery]

Karl Kleinpaste <karl@charcoal.com> writes:

> I regularly update to the latest beta or gamma XEmacs, and I keep very
> regularly updated in Oort Gnus.  I last updated Oort this morning, and
> I'm running 21.4.6 under Linux RH7.1.  No worries, for the most part;
> once in a blue moon, I get a coredump, but I have yet to trace it down
> to anything identifiable.  That happens perhaps once a week.  I have
> never seen a trace like the one you sent.  What's your platform?

sparc-sun-solaris2.8 (64-bit kernel, but XEmacs was built 32-bit)
Built with gcc 2.95.3, linked against X11R6.4.3 (not vendor libraries)

Sounds like I should investigate further and try to get a C core dump and
then report it directly to the XEmacs folks.  If I have time I'll do that,
but I'm not sure that I'll get a chance; I was seeing half-second delays
whenever I cut text out of a font-lock buffer (such as a message in
message mode) using 21.4.6, and that was so annoying that I would have
probably rolled back to 21.1.12 anyway.  (Does anyone know if that's the
font-lock problem alluded to somewhat mysteriously in the release
announcement for 21.4.6?)

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: Anyone using Oort with XEmacs 21.4.6?

[Russ Allbery]

Russ Allbery <rra@Stanford.EDU> writes:

> Sounds like I should investigate further and try to get a C core dump
> and then report it directly to the XEmacs folks.  If I have time I'll do
> that, but I'm not sure that I'll get a chance; I was seeing half-second
> delays whenever I cut text out of a font-lock buffer (such as a message
> in message mode) using 21.4.6, and that was so annoying that I would
> have probably rolled back to 21.1.12 anyway.  (Does anyone know if
> that's the font-lock problem alluded to somewhat mysteriously in the
> release announcement for 21.4.6?)

Figured out the delay; turns out it didn't have anything to do with
font-lock mode and instead had to do with the fact that new XEmacs
defaults to saving killed text in the X clipboard, which is painfully slow
and completely not worth doing (at least the way that I use Gnus).  A
simple:

(setq interprogram-cut-function nil)
(setq interprogram-paste-function nil)

takes care of it.

I'm back to using 21.4.6 full time, so I'll start watching for those
crashes again and try to get more debugging information if they happen.
They appear to coincide with the loading of byte-optimize, but don't
happen all the time.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>