11:04 p.m.
This bug report will be sent to the XEmacs Development Team,
not to your local site managers!!
Please write in English, because the XEmacs maintainers do not have
translators to read other languages for them.
Please describe as succinctly as possible:
- What happened.
- What you thought should have happened.
- Precisely what you were doing at the time.
Please also include any C or lisp back-traces that you may have.
================================================================
Dear Bug Team!
I have often had problems where my XEmacs would not finish updating a window,
loading a file, or font-locking a buffer, until I clicked the mouse outside the
window. Today, I updated my Cygwin and Cygwin-XEmacs and the problem is about
as bad as it has ever been.
I'm just trying to load certain small text files (20-50 lines), and I'm finding
that font-locking is not completing unless I click several times back and forth
outside the window and back in the window. Even with that, it's taking 10-20
seconds to load and view these files. Normally, on my 1ghz Athlon, this goes
much faster.
Note that I'm using the "sdesk" virtual window manager on Win2k.
================================================================
System Info to help track down your bug:
---------------------------------------
uname -a: CYGWIN_NT-5.0 TSUNAMI 1.3.10(0.51/3/2) 2002-02-25 11:14 i686 unknown
./configure '--with-dragndrop' '--with-postgresql=no'
'--with-x=no' '--bindir=/usr/local/bin/i686-pc-cygwin'
'--with-site-lisp=yes' '--with-ipv6-cname=no' '--with-netinstall'
XEmacs 21.4.8 "Honest Recruiter (Windows [3])" configured for
`i686-pc-cygwin'.
Compilation / Installation:
Source code location: /development/xemacs/xemacs-21.4-release
Installation prefix: /usr/local
Operating system description file: `s/cygwin32.h'
Machine description file: `m/intel386.h'
Compiler: gcc -I/usr/lib/../include/noX
-I/usr/lib/../include/noX -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes
-Wsign-compare -Wshadow -Wpointer-arith
Relocating allocator for buffers: no
GNU version of malloc: yes
Window System:
Compiling in support for the Microsoft window system.
Using MS-Windows menubars.
Using MS-Windows scrollbars.
Using MS-Windows dialog boxes.
Using MS-Windows native widgets.
Compiling in support for Drag'n'Drop (EXPERIMENTAL).
- Drag'n'Drop prototype: msw.
TTY:
Compiling in support for ncurses.
Images:
Compiling in support for GIF images (builtin).
Compiling in support for XPM images.
Compiling in support for PNG images.
Compiling in support for JPEG images.
Compiling in support for TIFF images.
Compiling in support for X-Face message headers.
Sound:
Compiling in support for sound (native).
Databases:
Compiling in support for GNU DBM.
Internationalization:
Compiling in support for file coding.
Mail:
Compiling in support for POP mail retrieval.
Other Features:
Inhibiting IPv6 canonicalization at startup.
Compiling in support for dynamic shared object modules.
Load-Path Lisp Shadows:
----------------------
(/home/dmkarr/ntlisp/clearcase
/usr/local/lib/xemacs/xemacs-packages/lisp/clearcase/clearcase
/home/dmkarr/ntlisp/eieio-0.17beta4/tree
/usr/local/lib/xemacs/xemacs-packages/lisp/eieio/tree
/home/dmkarr/ntlisp/eieio-0.17beta4/eieio
/usr/local/lib/xemacs/xemacs-packages/lisp/eieio/eieio
/home/dmkarr/ntlisp/eieio-0.17beta4/eieio-tests
/usr/local/lib/xemacs/xemacs-packages/lisp/eieio/eieio-tests
/home/dmkarr/ntlisp/eieio-0.17beta4/eieio-speedbar
/usr/local/lib/xemacs/xemacs-packages/lisp/eieio/eieio-speedbar
/home/dmkarr/ntlisp/eieio-0.17beta4/eieio-opt
/usr/local/lib/xemacs/xemacs-packages/lisp/eieio/eieio-opt
/home/dmkarr/ntlisp/eieio-0.17beta4/eieio-doc
/usr/local/lib/xemacs/xemacs-packages/lisp/eieio/eieio-doc
/home/dmkarr/ntlisp/eieio-0.17beta4/eieio-custom
/usr/local/lib/xemacs/xemacs-packages/lisp/eieio/eieio-custom
/home/dmkarr/ntlisp/eieio-0.17beta4/eieio-comp
/usr/local/lib/xemacs/xemacs-packages/lisp/eieio/eieio-comp
/home/dmkarr/ntlisp/eieio-0.17beta4/eieio-base
/usr/local/lib/xemacs/xemacs-packages/lisp/eieio/eieio-base
/home/dmkarr/ntlisp/eieio-0.17beta4/compare-strings
/usr/local/lib/xemacs/xemacs-packages/lisp/eieio/compare-strings
/home/dmkarr/ntlisp/eieio-0.17beta4/chart
/usr/local/lib/xemacs/xemacs-packages/lisp/eieio/chart
/home/dmkarr/ntlisp/eieio-0.17beta4/call-tree
/usr/local/lib/xemacs/xemacs-packages/lisp/eieio/call-tree
/usr/local/lib/xemacs/xemacs-packages/lisp/ps-print/ps-print
/usr/local/lib/xemacs/xemacs-packages/lisp/ps-print-nomule/ps-print
/home/dmkarr/ntlisp/semantic-1.4beta14/working
/usr/local/lib/xemacs/xemacs-packages/lisp/semantic/working
/home/dmkarr/ntlisp/semantic-1.4beta14/sformat
/usr/local/lib/xemacs/xemacs-packages/lisp/semantic/sformat
/home/dmkarr/ntlisp/semantic-1.4beta14/senator
/usr/local/lib/xemacs/xemacs-packages/lisp/semantic/senator
/home/dmkarr/ntlisp/semantic-1.4beta14/semanticdb
/usr/local/lib/xemacs/xemacs-packages/lisp/semantic/semanticdb
/home/dmkarr/ntlisp/semantic-1.4beta14/semantic
/usr/local/lib/xemacs/xemacs-packages/lisp/semantic/semantic
/home/dmkarr/ntlisp/semantic-1.4beta14/semantic-util
/usr/local/lib/xemacs/xemacs-packages/lisp/semantic/semantic-util
/home/dmkarr/ntlisp/semantic-1.4beta14/semantic-texi
/usr/local/lib/xemacs/xemacs-packages/lisp/semantic/semantic-texi
/home/dmkarr/ntlisp/semantic-1.4beta14/semantic-scm
/usr/local/lib/xemacs/xemacs-packages/lisp/semantic/semantic-scm
/home/dmkarr/ntlisp/semantic-1.4beta14/semantic-sb
/usr/local/lib/xemacs/xemacs-packages/lisp/semantic/semantic-sb
/home/dmkarr/ntlisp/semantic-1.4beta14/semantic-make
/usr/local/lib/xemacs/xemacs-packages/lisp/semantic/semantic-make
/home/dmkarr/ntlisp/semantic-1.4beta14/semantic-load
/usr/local/lib/xemacs/xemacs-packages/lisp/semantic/semantic-load
/home/dmkarr/ntlisp/semantic-1.4beta14/semantic-java
/usr/local/lib/xemacs/xemacs-packages/lisp/semantic/semantic-java
/home/dmkarr/ntlisp/semantic-1.4beta14/semantic-imenu
/usr/local/lib/xemacs/xemacs-packages/lisp/semantic/semantic-imenu
/home/dmkarr/ntlisp/semantic-1.4beta14/semantic-el
/usr/local/lib/xemacs/xemacs-packages/lisp/semantic/semantic-el
/home/dmkarr/ntlisp/semantic-1.4beta14/semantic-ctxt
/usr/local/lib/xemacs/xemacs-packages/lisp/semantic/semantic-ctxt
/home/dmkarr/ntlisp/semantic-1.4beta14/semantic-c
/usr/local/lib/xemacs/xemacs-packages/lisp/semantic/semantic-c
/home/dmkarr/ntlisp/semantic-1.4beta14/semantic-bnf
/usr/local/lib/xemacs/xemacs-packages/lisp/semantic/semantic-bnf
/home/dmkarr/ntlisp/semantic-1.4beta14/document
/usr/local/lib/xemacs/xemacs-packages/lisp/semantic/document
/home/dmkarr/ntlisp/semantic-1.4beta14/document-vars
/usr/local/lib/xemacs/xemacs-packages/lisp/semantic/document-vars
/home/dmkarr/ntlisp/speedbar-0.14beta4/speedbar
/usr/local/lib/xemacs/xemacs-packages/lisp/speedbar/speedbar
/home/dmkarr/ntlisp/speedbar-0.14beta4/sb-w3
/usr/local/lib/xemacs/xemacs-packages/lisp/speedbar/sb-w3
/home/dmkarr/ntlisp/speedbar-0.14beta4/sb-texinfo
/usr/local/lib/xemacs/xemacs-packages/lisp/speedbar/sb-texinfo
/home/dmkarr/ntlisp/speedbar-0.14beta4/sb-rmail
/usr/local/lib/xemacs/xemacs-packages/lisp/speedbar/sb-rmail
/home/dmkarr/ntlisp/speedbar-0.14beta4/sb-info
/usr/local/lib/xemacs/xemacs-packages/lisp/speedbar/sb-info
/home/dmkarr/ntlisp/speedbar-0.14beta4/sb-image
/usr/local/lib/xemacs/xemacs-packages/lisp/speedbar/sb-image
/home/dmkarr/ntlisp/speedbar-0.14beta4/sb-gud
/usr/local/lib/xemacs/xemacs-packages/lisp/speedbar/sb-gud
/home/dmkarr/ntlisp/speedbar-0.14beta4/rpm
/usr/local/lib/xemacs/xemacs-packages/lisp/speedbar/rpm
/home/dmkarr/ntlisp/speedbar-0.14beta4/dframe
/usr/local/lib/xemacs/xemacs-packages/lisp/speedbar/dframe
/home/dmkarr/ntlisp/speedbar-0.14beta4/bigclock
/usr/local/lib/xemacs/xemacs-packages/lisp/speedbar/bigclock
/home/dmkarr/ntlisp/flyspell
/usr/local/lib/xemacs/xemacs-packages/lisp/text-modes/flyspell
/home/dmkarr/ntlisp/compile2/compile
/usr/local/lib/xemacs/xemacs-packages/lisp/xemacs-base/compile)
Installed XEmacs Packages:
-------------------------
((zenirc:version 1.13 :type regular)
(xslt-process :version 1.07 :type regular)
(xslide :version 1.01 :type regular)
(xemacs-devel :version 1.44 :type single-file)
(xemacs-base :version 1.63 :type regular)
(w3 :version 1.23 :type regular)
(vm :version 7.04 :type regular)
(viper :version 1.34 :type regular)
(view-process :version 1.11 :type regular)
(vhdl :version 1.15 :type regular)
(vc-cc :version 1.18 :type regular)
(vc :version 1.3 :type regular)
(tramp :version 1.05 :type regular)
(tpu :version 1.12 :type regular)
(tooltalk :version 1.13 :type regular)
(tm :version 1.32 :type regular)
(time :version 1.11 :type regular)
(textools :version 1.12 :type regular)
(text-modes :version 1.43 :type single-file)
(texinfo :version 1.2 :type regular)
(supercite :version 1.19 :type regular)
(strokes :version 1.08 :type regular)
(speedbar :version 1.23 :type regular)
(sounds-wav :version 1.1 :type regular)
(sounds-au :version 1.1 :type regular)
(slider :version 1.13 :type regular)
(sieve :version 1.02 :type regular)
(sh-script :version 1.15 :type regular)
(sgml :version 1.08 :type regular)
(semantic :version 1.12 :type regular)
(scheme :version 1.11 :type regular)
(rmail :version 1.13 :type regular)
(reftex :version 1.25 :type regular)
(psgml :version 1.28 :type regular)
(ps-print-nomule :version 1.05 :type regular)
(ps-print :version 1.04 :type regular)
(prog-modes
:version
1
.56
:type
single-file)
(pcomplete :version 1.01 :type regular)
(pcl-cvs :version 1.61 :type regular)
(pc :version 1.22 :type single-file)
(os-utils :version 1.28 :type single-file)
(net-utils :version 1.24 :type single-file)
(mmm-mode :version 1.0 :type regular)
(misc-games :version 1.15 :type single-file)
(mine :version 1.14 :type regular)
(mh-e :version 1.14 :type regular)
(mew :version 1.17 :type regular)
(mailcrypt :version 2.11 :type regular)
(mail-lib :version 1.46 :type regular)
(liece :version 1.04 :type regular)
(jde :version 1.35 :type regular)
(ispell :version 1.24 :type regular)
(ilisp :version 1.22 :type regular)
(igrep :version 1.08 :type regular)
(idlwave :version 1.25 :type regular)
(ibuffer :version 1.07 :type regular)
(hm--html-menus :version 1.18 :type regular)
(haskell-mode :version 1.03 :type regular)
(gnus :version 1.6 :type regular)
(gnats :version 1.14 :type regular)
(games :version 1.13 :type regular)
(fsf-compat :version 1.11 :type single-file)
(frame-icon :version 1.09 :type regular)
(forms :version 1.14 :type regular)
(footnote :version 1.15 :type regular)
(eudc :version 1.36 :type regular)
(eterm :version 1.13 :type regular)
(eshell :version 1.03 :type regular)
(emerge :version 1.09 :type regular)
(elib :version 1.1 :type single-file)
(eieio :version 1.02 :type regular)
(eicq :version 1.05 :type regular)
(efs :version 1.29 :type regular)
(edt :version 1.12 :type regular)
(edit-utils :version 1.85 :type single-file)
(ediff :version 1.41 :type regular)
(edebug :version 1.14 :type regular)
(dired :version 1.12 :type regular)
(dictionary :version 1.11 :type regular)
(debug :version 1.15 :type regular)
(crisp :version 1.12 :type regular)
(cookie :version 1.14 :type regular)
(clearcase :version 1.03 :type regular)
(cc-mode :version 1.28 :type regular)
(calendar :version 1.18 :type regular)
(calc :version 1.23 :type regular)
(c-support :version 1.16 :type single-file)
(build :version 1.05 :type regular)
(bbdb :version 1.2 :type regular)
(auctex :version 1.31 :type regular)
(apel :version 1.23 :type regular)
(ada :version 1.1 :type regular)
(Sun :version 1.13 :type regular))
Features:
--------
(xemacsbug shadow jde executable jde-package jde-import jde-which-method
jde-stat jde-javadoc jde-javadoc-gen jde-java-font-lock jde-bug jde-dbs jde-dbo
jde-help jde-wiz jde-widgets tree-widget jde-complete beanshell jde-gen
jde-make jde-run jde-db jde-parse jde-imenu regexp-opt jde-java-grammar
semantic-java document document-vars sformat avltree stack-m elib-node
semantic-bnf senator hippie-exp semantic-imenu semantic-ctxt semanticdb
eieio-base compare-strings semantic-sb speedbar sb-image dframe gud tags etags
jde-compile psgml-dtd psgml-parse psgml-edit tempo psgml-html debug flow-fill
netrc smiley gnus-cite gnus-picon annotations sort rect w3-style bbdb-w3
browse-url w3-hot url-file url-cache w3-xemac w3-xemacs w3-toolbar xbm-button
xpm-button w3-forms images url-http url-cookie urlauth w3 w3-menu url-news
url-gw w3-script w3-jscript w3-elisp w3-java cus-edit cus-load w3-emulate
w3-auto w3-parse url mm w3-display w3-mouse w3-imap w3-widget w3-vars
w3-keyword w3-cus url-parse url-vars css font mule-sysdp w3-cfg w3-sysdp
gnus-async gnus-score score-mode gnus-ml gnus-msg disp-table gnus-topic nndraft
nnmh nndoc pop3 nnml gnus-cache nnfolder bbdb-gnus gnus-art mm-uu mm-view
gnus-sum gnus-group gnus-undo nnmail bbdb-snarf bbdb-com nntp nnoo gnus-start
gnus-range gnus-spec gnus-int gnus-win gnus gnus-ems gnus-xmas bbdb timezone vc
vc-hooks psgml-xemacs sgml-mode psgml message-x cperl-mode efs-x19.15 efs-fnh
efs-ovwrt efs-cu efs-netrc efs-defun efs analog ps-print lpr msb mail-source
format-spec message messagexmas mml mm-decode mm-encode mailcap mm-bodies
uudecode mail-parse rfc2045 rfc2231 rfc2047 gnus-util qp ietf-drums time-date
parse-time mail-abbrevs nnheader nnheaderxm mm-util mail-prsvr mail-utils
mailheader smtpmail time-stamp sendmail rfc822 idl-font-lock supercite
mail-extr regi shell comint ring gnuserv rsz-minibuf cc-mode cc-align cc-cmds
cc-engine cc-styles cc-langs cc-vars wid-edit cc-menus imenu cc-defs filladapt
env buffer-cycle time ffap paren mic-paren ecb ecb-face ecb-cycle
ecb-compilation ecb-eshell ecb-navigate ecb-help ecb-mode-line ecb-layout
compile2 compile request-directory generic-filter command-window
window-manip-fns hlist declare-object ecb-util tree-buffer overlay
semantic-load eieio advice advice-preload eieio-comp semantic-util-modes eldoc
timer semantic-util font-lock cus-face semantic pp assoc working edmacro
iswitchb zenirc-autoloads xslt-process-autoloads xslide-autoloads
xemacs-devel-autoloads xemacs-base-autoloads w3-autoloads vm-autoloads
viper-autoloads view-process-autoloads vhdl-autoloads vc-cc-autoloads
vc-autoloads tramp-autoloads tpu-autoloads tooltalk-autoloads tm-autoloads
time-autoloads textools-autoloads text-modes-autoloads texinfo-autoloads
supercite-autoloads strokes-autoloads speedbar-autoloads sounds-wav-autoloads
sounds-au-autoloads slider-autoloads sieve-autoloads sh-script-autoloads
sgml-autoloads semantic-autoloads scheme-autoloads rmail-autoloads
reftex-autoloads psgml-autoloads ps-print-nomule-autoloads ps-print-autoloads
prog-modes-autoloads pcomplete-autoloads pcl-cvs-autoloads pc-autoloads
os-utils-autoloads net-utils-autoloads mmm-mode-autoloads misc-games-autoloads
mine-autoloads mh-e-autoloads mew-autoloads mailcrypt-autoloads
mail-lib-autoloads liece-autoloads jde-autoloads ispell-autoloads
ilisp-autoloads igrep-autoloads idlwave-autoloads ibuffer-autoloads
hm--html-menus-autoloads haskell-mode-autoloads gnus-autoloads gnats-autoloads
games-autoloads fsf-compat-autoloads frame-icon-autoloads forms-autoloads
footnote-autoloads eudc-autoloads eterm-autoloads eshell-autoloads
emerge-autoloads elib-autoloads eieio-autoloads eicq-autoloads efs-autoloads
edt-autoloads edit-utils-autoloads ediff-autoloads edebug-autoloads
dired-autoloads dictionary-autoloads debug-autoloads crisp-autoloads
cookie-autoloads clearcase-autoloads cc-mode-autoloads calendar-autoloads
calc-autoloads c-support-autoloads build-autoloads bbdb-autoloads
auctex-autoloads apel-autoloads ada-autoloads Sun-autoloads lisp-autoloads
loadhist auto-show fontl-hooks code-cmds gutter-items menubar-items x-menubar
dragdrop mode-motion mouse itimer auto-save lisp-mode easymenu iso8859-1 page
buff-menu lib-complete help-nomule cus-file derived frame text-props obsolete
cus-start custom widget cl-extra mini-cl cl cl-19 packages backquote
very-early-lisp file-coding mswindows-scrollbars mswindows tty-frames tty
toolbar native-sound scrollbar unix-processes multicast network-streams
subprocesses modules menu-accelerator-support menubar dbm md5 xemacs gutter
tiff png gif jpeg xface xpm xbm lisp-float-type cygwin32 dragdrop-api dialog
devices window-system base64)
Recent keystrokes:
-----------------
. C-x . C-x . C-x . C-f C-x C-d m e d i a T y p e C-x
o C-x b A l C-g C-x C-e C-x s C-x s i n d BS BS BS
f i n d j a v a C-j C-e C-n C-n C-n C-n C-x F RET button1
button1up button1 button1up button1 button1up button1
button1up button1 button1up button1 button1up button1
button1up button1 button1up button1 button1up button1
button1up button1 button1up button1 button1up button1
button1up button1 button1up kp-home C-x o C-x C-s M-x
r e p o r t - e m TAB RET
Recent messages (most recent first):
-----------------------------------
Parsing /home/dmkarr/.mailrc...
Loading xemacsbug...done
Loading xemacsbug...
Wrote /home/dmkarr/java/musicindex/ejb/conf/ejb-jar.xml
Setting JDE variables to startup values...
Loading jde...done
jde-java-font-lock: building names cache...empty
jde-java-font-lock: building names cache...
Loading regexp-opt...done
Loading regexp-opt...
Loading jde...
Quit
Fontifying...done
Fontifying...
Fontifying...done
Fontifying...
Fontifying...done
Fontifying...
Fontifying...done
Fontifying...
11:36 p.m.
At 03:04 PM 6/20/02 -0700, David M. Karr wrote:
I have often had problems where my XEmacs would not finish updating a
window,
loading a file, or font-locking a buffer, until I clicked the mouse
outside the
window. Today, I updated my Cygwin and Cygwin-XEmacs and the problem is about
as bad as it has ever been.
I've never seen this. Is it for particular files?
I'm just trying to load certain small text files (20-50 lines),
and I'm
finding
that font-locking is not completing unless I click several times back and
forth
outside the window and back in the window. Even with that, it's taking 10-20
seconds to load and view these files. Normally, on my 1ghz Athlon, this goes
much faster.
Can you try without sdesk?
andy
12:13 a.m.
>>>> "Andy" == Andy Piper <andyp(a)bea.com>
writes:
Andy> At 03:04 PM 6/20/02 -0700, David M. Karr wrote:
> I have often had problems where my XEmacs would not finish
updating a window,
> loading a file, or font-locking a buffer, until I clicked the mouse outside
> the
> window. Today, I updated my Cygwin and Cygwin-XEmacs and the
problem is about
> as bad as it has ever been.
Andy> I've never seen this. Is it for particular files?
I've seen it in the past when I press Return on a command in a shell buffer,
and also displaying notes to read in GNUS. I just saw it again when I started
to reply to this note. The "font-locking" progress panel appeared and stayed
there for a few seconds without changing. As soon as I clicked outside of the
window, on the desktop, the progress bar filled up, the panel went away, and
the reply window appeared.
> I'm just trying to load certain small text files (20-50
lines), and I'm
> finding
> that font-locking is not completing unless I click several times
back and
> forth
> outside the window and back in the window. Even with that,
it's taking 10-20
> seconds to load and view these files. Normally, on my 1ghz Athlon, this goes
> much faster.
Andy> Can you try without sdesk?
Before I do that, tell me exactly what you want me to try. The simplest test
would be for me to move all my windows to the first workspace (or dismiss
them), then exit sDesk, and try loading a file, or do you need me to reboot and
kill sDesk before I start XEmacs?
--
===================================================================
David M. Karr ; Java/J2EE/XML/Unix/C++
dmkarr(a)earthlink.net
12:34 a.m.
At 04:13 PM 6/20/02 -0700, David M. Karr wrote:
I've seen it in the past when I press Return on a command in a
shell buffer,
and also displaying notes to read in GNUS. I just saw it again when I started
to reply to this note. The "font-locking" progress panel appeared and stayed
there for a few seconds without changing. As soon as I clicked outside of the
window, on the desktop, the progress bar filled up, the panel went away, and
the reply window appeared.
This used to happen on UNIX, its to do with the fact that XEmacs needs to
process events in order for widget updates to be visible. If it thinks
there is an event but there isn't then you see this behavior while it
blocks waiting for an event.
Before I do that, tell me exactly what you want me to try. The
simplest test
would be for me to move all my windows to the first workspace (or dismiss
them), then exit sDesk, and try loading a file, or do you need me to
reboot and
kill sDesk before I start XEmacs?
I have no idea. But VWM's seem to have caused us problems in the past.
Exiting sdesk should be enough.
andy
12:24 a.m.
>>>> "Andy" == Andy Piper <andyp(a)bea.com>
writes:
Andy> At 03:04 PM 6/20/02 -0700, David M. Karr wrote:
> I have often had problems where my XEmacs would not finish
updating a window,
> loading a file, or font-locking a buffer, until I clicked the mouse outside
> the
> window. Today, I updated my Cygwin and Cygwin-XEmacs and the
problem is about
> as bad as it has ever been.
Andy> I've never seen this. Is it for particular files?
> I'm just trying to load certain small text files (20-50
lines), and I'm
> finding
> that font-locking is not completing unless I click several times
back and
> forth
> outside the window and back in the window. Even with that,
it's taking 10-20
> seconds to load and view these files. Normally, on my 1ghz Athlon, this goes
> much faster.
Andy> Can you try without sdesk?
For what it's worth, I moved all my Windows to one workspace and killed sDesk,
and I still see the problem. I also noticed that in my clicking back and
forth, if I clicked back on the XEmacs frame by clicking on the title bar, it
had no effect. It seemed to only make a difference if I clicked inside the
frame, in one of the XEmacs windows. Loading a 10-line Java source file (JDE
enabled) took about 20 seconds going through this process, almost all of it
spent in the font-lock progress panel.
--
===================================================================
David M. Karr ; Java/J2EE/XML/Unix/C++
dmkarr(a)earthlink.net
4:11 a.m.
So out of curiosity are you running any sub-processes in XEmacs (e.g. a
shell) when you see the problem, if so can you try without?
Thanks
andy
-----Original Message-----
From: xemacs-beta-admin(a)xemacs.org
[mailto:xemacs-beta-admin＠xemacs.org]On Behalf Of David M. Karr
Sent: Thursday, June 20, 2002 4:24 PM
To: xemacs-beta(a)xemacs.org
Subject: Re: Loading even small files reqs. clicking in/out multi. times
>>>>> "Andy" == Andy Piper <andyp(a)bea.com> writes:
Andy> At 03:04 PM 6/20/02 -0700, David M. Karr wrote:
>> I have often had problems where my XEmacs would not finish
updating a window,
>> loading a file, or font-locking a buffer, until I clicked
the mouse outside
>> the
>> window. Today, I updated my Cygwin and Cygwin-XEmacs and
the problem is about
>> as bad as it has ever been.
Andy> I've never seen this. Is it for particular files?
>> I'm just trying to load certain small text files (20-50
lines), and I'm
>> finding
>> that font-locking is not completing unless I click several
times back and
>> forth
>> outside the window and back in the window. Even with
that, it's taking 10-20
>> seconds to load and view these files. Normally, on my
1ghz Athlon, this goes
>> much faster.
Andy> Can you try without sdesk?
For what it's worth, I moved all my Windows to one workspace and
killed sDesk,
and I still see the problem. I also noticed that in my clicking back and
forth, if I clicked back on the XEmacs frame by clicking on the
title bar, it
had no effect. It seemed to only make a difference if I clicked
inside the
frame, in one of the XEmacs windows. Loading a 10-line Java
source file (JDE
enabled) took about 20 seconds going through this process, almost
all of it
spent in the font-lock progress panel.
--
===================================================================
David M. Karr ; Java/J2EE/XML/Unix/C++
dmkarr(a)earthlink.net
6:14 a.m.
>>>> "Andy" == Andy Piper
<andy(a)xemacs.org> writes:
Andy> So out of curiosity are you running any sub-processes in XEmacs (e.g. a
Andy> shell) when you see the problem, if so can you try without?
It doesn't happen all the time, but once it starts happening in a session, it
continues until I restart XEmacs.
So you're suggesting that when I start to see it happen in a session, I kill
all of my shell buffers and see if it still occurs in that session?
I also use Gnus, and I find that I sometimes see many "useless" processes
(listed in the "list-processes" buffer). The next time it occurs, I'll
check
for the presence of those processes, and any others.
--
===================================================================
David M. Karr ; Java/J2EE/XML/Unix/C++
dmkarr(a)earthlink.net
9:19 p.m.
>>>> "Andy" == Andy Piper
<andy(a)xemacs.org> writes:
Andy> So out of curiosity are you running any sub-processes in XEmacs (e.g. a
Andy> shell) when you see the problem, if so can you try without?
Ok, it just started happening again, so I looked at my process list, which this
is an excerpt of:
------------------------
Proc Status Buffer Tty Command
---- ------ ------ --- -------
shell<1> run *shell-2* /dev/tty13 bash -i
nntpd<2> open *server newsgroups.borland.com nntp *nntpd** (none) network
stream connection nntp(a)newsgroups.borland.com
nntpd<1> open *server newsgroups.bea.com nntp *nntpd** (none) network stream
connection nntp(a)newsgroups.bea.com
nntpd open *server news.earthlink.net nntp *nntpd** (none) network stream
connection nntp(a)news.earthlink.net
shell<4> run *shell-4* /dev/tty16 bash -i
shell<3> run *shell-3* /dev/tty15 bash -i
WWW<72> open *W3GRAPH*<73> (none) network stream connection
80(a)cfadvisor.webcoretech.com
[41 similar items elided]
WWW<30> open *W3GRAPH*<31> (none) network stream connection
80(a)cfadvisor.webcoretech.com
shell<2> run *shell-1* /dev/tty14 bash -i
shell run *shell* /dev/tty12 bash -i
gnuserv run (none) /dev/tty11 gnuserv
------------------------
I then went to my "*scratch*" buffer and executed '(kill-buffer "
*W3GRAPH*<73>")' 43 times, using each buffer name associated with each
"WWW"
process. At the end of this, no "WWW" processes were left, and when I tried to
load another similar file that was causing the same behavior as before, it did
not display the "halting" behavior, like it did before I deleted those buffers.
I didn't try to kill any other processes or delete any buffers associated with
any other processes.
So, it seems as if this "halting" behavior is at least indirectly connected to
these phantom network connections that Gnus opens and fails to close, for
whatever reason.
--
===================================================================
David M. Karr ; Java/J2EE/XML/Unix/C++
dmkarr(a)earthlink.net
9:45 p.m.
At 01:19 PM 6/21/2002 -0700, David M. Karr wrote:
>>>>> "Andy" == Andy Piper
<andy(a)xemacs.org> writes:
Andy> So out of curiosity are you running any sub-processes in XEmacs
(e.g. a
Andy> shell) when you see the problem, if so can you try without?
Ok, it just started happening again, so I looked at my process list, which
this
is an excerpt of:
------------------------
Proc Status Buffer Tty Command
---- ------ ------ --- -------
shell<1> run *shell-2* /dev/tty13
bash -i
nntpd<2> open *server newsgroups.borland.com
nntp *nntpd** (none) network stream connection nntp(a)newsgroups.borland.com
nntpd<1> open *server newsgroups.bea.com
nntp *nntpd** (none) network stream connection nntp(a)newsgroups.bea.com
nntpd open *server news.earthlink.net
nntp *nntpd** (none) network stream connection nntp(a)news.earthlink.net
shell<4> run *shell-4* /dev/tty16
bash -i
shell<3> run *shell-3* /dev/tty15
bash -i
WWW<72> open *W3GRAPH*<73> (none) network
stream connection 80(a)cfadvisor.webcoretech.com
[41 similar items elided]
WWW<30> open *W3GRAPH*<31> (none) network
stream connection 80(a)cfadvisor.webcoretech.com
shell<2> run *shell-1* /dev/tty14
bash -i
shell run *shell* /dev/tty12
bash -i
gnuserv run (none) /dev/tty11
gnuserv
------------------------
I then went to my "*scratch*" buffer and executed '(kill-buffer "
*W3GRAPH*<73>")' 43 times, using each buffer name associated with each
"WWW"
Hmmn, so as a further matter of interest you weren't near the magic number
64 for number of sub-processes?
process. At the end of this, no "WWW" processes were left,
and when I
tried to
load another similar file that was causing the same behavior as before, it did
not display the "halting" behavior, like it did before I deleted those
buffers.
I didn't try to kill any other processes or delete any buffers associated with
any other processes.
So, it seems as if this "halting" behavior is at least indirectly connected to
these phantom network connections that Gnus opens and fails to close, for
whatever reason.
Does anyone know what code opens these, and what code (if any) tries to
close these?
andy
9:58 p.m.
>>>> "Andy" == Andy Piper <andyp(a)bea.com>
writes:
Andy> At 01:19 PM 6/21/2002 -0700, David M. Karr wrote:
> >>>>> "Andy" == Andy Piper
<andy(a)xemacs.org> writes:
>
Andy> So out of curiosity are you running any sub-processes in XEmacs
> (e.g. a
Andy> shell) when you see the problem, if so can you try without?
>
> Ok, it just started happening again, so I looked at my process list, which
> this
> is an excerpt of:
>
> ------------------------
> Proc Status Buffer Tty Command
> ---- ------ ------ --- -------
> WWW<72> open *W3GRAPH*<73> (none) network
> stream connection 80(a)cfadvisor.webcoretech.com
> [41 similar items elided]
> WWW<30> open *W3GRAPH*<31> (none) network
> stream connection 80(a)cfadvisor.webcoretech.com
> ------------------------
> I then went to my "*scratch*" buffer and executed '(kill-buffer "
> *W3GRAPH*<73>")' 43 times, using each buffer name associated with each
"WWW"
Andy> Hmmn, so as a further matter of interest you weren't near the magic
number 64
Andy> for number of sub-processes?
Well, I'm not certain. If the output of "list-processes" really shows all
of
your sub-processes, then I was probably still under 64. I probably had 52-53
processes. However, I'm a little uncertain exactly what entries in that list
signify. I had thought that if I execute '(kill-process
"WWW<72>")' it would
directly kill that process. However, this gives me an error indicating "no
such process" (I don't remember the exact error message). So, either the
"Proc" column doesn't represent a process name you can send to
"kill-process",
or many of those entries don't represent real processes.
--
===================================================================
David M. Karr ; Java/J2EE/XML/Unix/C++
dmkarr(a)earthlink.net
10:26 p.m.
At 01:58 PM 6/21/2002 -0700, David M. Karr wrote:
Well, I'm not certain. If the output of
"list-processes" really shows all of
your sub-processes, then I was probably still under 64. I probably had 52-53
processes. However, I'm a little uncertain exactly what entries in that list
signify. I had thought that if I execute '(kill-process
"WWW<72>")' it would
directly kill that process. However, this gives me an error indicating "no
such process" (I don't remember the exact error message). So, either the
"Proc" column doesn't represent a process name you can send to
"kill-process",
or many of those entries don't represent real processes.
I guess it would be helpful to know if its a particular type of process
that causes the problem or the number of processes or a combination of both.
andy
10:33 p.m.
>>>> "Andy" == Andy Piper <andyp(a)bea.com>
writes:
Andy> At 01:58 PM 6/21/2002 -0700, David M. Karr wrote:
> Well, I'm not certain. If the output of
"list-processes" really shows all of
> your sub-processes, then I was probably still under 64. I probably had 52-53
> processes. However, I'm a little uncertain exactly what entries in that list
> signify. I had thought that if I execute '(kill-process
"WWW<72>")' it would
> directly kill that process. However, this gives me an error indicating "no
> such process" (I don't remember the exact error message). So, either the
> "Proc" column doesn't represent a process name you can send to
"kill-process",
> or many of those entries don't represent real processes.
Andy> I guess it would be helpful to know if its a particular type of process that
Andy> causes the problem or the number of processes or a combination of both.
Ok, next time it hits, I'll recheck the symptom after deleting each WWW buffer.
I'll also probably try deleting shell buffers one by one, checking the symptom
each time. I think I might try manually creating a large number of shell
buffers, to see if that causes it.
--
===================================================================
David M. Karr ; Java/J2EE/XML/Unix/C++
dmkarr(a)earthlink.net
4:47 a.m.
>>>> "David" == David M Karr
<dmkarr(a)earthlink.net> writes:
>>>> "Andy" == Andy Piper <andyp(a)bea.com>
writes:
Andy> At 01:58 PM 6/21/2002 -0700, David M. Karr wrote:
>> Well, I'm not certain. If the output of
"list-processes" really shows all of
>> your sub-processes, then I was probably still under 64. I probably had 52-53
>> processes. However, I'm a little uncertain exactly what entries in that
list
>> signify. I had thought that if I execute '(kill-process
"WWW<72>")' it would
>> directly kill that process. However, this gives me an error indicating "no
>> such process" (I don't remember the exact error message). So, either
the
>> "Proc" column doesn't represent a process name you can send to
"kill-process",
>> or many of those entries don't represent real processes.
Andy> I guess it would be helpful to know if its a particular type of process that
Andy> causes the problem or the number of processes or a combination of both.
David> Ok, next time it hits, I'll recheck the symptom after deleting each WWW
buffer.
David> I'll also probably try deleting shell buffers one by one, checking the
symptom
David> each time. I think I might try manually creating a large number of shell
David> buffers, to see if that causes it.
Ok, I was in a state where the symptom was not occurring. I recorded a
keyboard macro that created a new shell buffer, and I executed it 50 times.
This took quite a while to finish. After a while I discovered that I could get
it to finish faster by clicking out of the frame, and back in, just like with
loading files. After it finished creating the shell buffers, I had the symptom
back. I also noticed that the CPU was pegged all throughout this, after I
started to create the shell buffers.
I then went through the process of deleting a shell buffer and checking the
symptom. I did this until I got down to about 30 processes. At that point the
symptom went away (and CPU usage went down to normal). However, I then
couldn't get the symptom back by adding back more shell buffers.
I wonder if this problem has something to do with creating numerous processes
in a very short time period. Whenever I've seen this happen with the "WWW"
processes, they're all to the same URL, so they were likely from the same email
message, so those connections were probably all created at just about the same
time.
--
===================================================================
David M. Karr ; Java/J2EE/XML/Unix/C++
dmkarr(a)earthlink.net
7:05 a.m.
I wonder if this problem has something to do with creating
numerous processes
in a very short time period. Whenever I've seen this happen with
the "WWW"
processes, they're all to the same URL, so they were likely from
the same email
message, so those connections were probably all created at just
about the same
time.
Unfortunately this probably means that the problem is buried inside of the
cygwin implementation of select().
andy
10:08 p.m.
>>>> "Andy" == Andy Piper <andyp(a)bea.com>
writes:
I have another gripe about Gnus leaking handles like crazy when
popping mail in native XEmacs (21.1.14, 21.4.X, 21.5.6 are all showing
the symptom).
Three handles are left over for each pop.
Adrian
Andy> At 01:19 PM 6/21/2002 -0700, David M. Karr wrote:
> >>>>> "Andy" == Andy Piper
<andy(a)xemacs.org> writes:
>
Andy> So out of curiosity are you running any sub-processes in
Andy> XEmacs (e.g. a
Andy> shell) when you see the problem, if so can you try without?
>
> Ok, it just started happening again, so I looked at my process list,
> which this
> is an excerpt of:
>
> ------------------------
> Proc Status Buffer Tty Command
> ---- ------ ------ --- -------
> shell<1> run *shell-2* /dev/tty13 bash -i
> nntpd<2> open *server newsgroups.borland.com nntp *nntpd**
(none)
> network stream connection nntp(a)newsgroups.borland.com
> nntpd<1> open *server newsgroups.bea.com nntp *nntpd**
(none)
> network stream connection nntp(a)newsgroups.bea.com
> nntpd open *server news.earthlink.net nntp *nntpd** (none)
network
> stream connection nntp(a)news.earthlink.net
> shell<4> run *shell-4* /dev/tty16 bash -i
> shell<3> run *shell-3* /dev/tty15 bash -i
> WWW<72> open *W3GRAPH*<73> (none) network stream
connection
> 80(a)cfadvisor.webcoretech.com
> [41 similar items elided]
> WWW<30> open *W3GRAPH*<31> (none) network stream connection
> 80(a)cfadvisor.webcoretech.com
> shell<2> run *shell-1* /dev/tty14 bash -i
> shell run *shell* /dev/tty12 bash -i
> gnuserv run (none) /dev/tty11 gnuserv
> ------------------------
>
> I then went to my "*scratch*" buffer and executed '(kill-buffer "
> *W3GRAPH*<73>")' 43 times, using each buffer name associated with each
"WWW"
Andy> Hmmn, so as a further matter of interest you weren't near the magic
Andy> number 64 for number of sub-processes?
> process. At the end of this, no "WWW" processes were
left, and when
> I tried to
> load another similar file that was causing the same behavior as
before, it did
> not display the "halting" behavior, like it did before I deleted
> those buffers.
> I didn't try to kill any other processes or delete any
buffers associated with
> any other processes.
>
> So, it seems as if this "halting" behavior is at least indirectly connected
to
> these phantom network connections that Gnus opens and fails to close, for
> whatever reason.
Andy> Does anyone know what code opens these, and what code (if any) tries
Andy> to close these?
Andy> andy
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
10:25 p.m.
At 11:08 PM 6/21/2002 +0200, Adrian Aichner wrote:
I have another gripe about Gnus leaking handles like crazy when
popping mail in native XEmacs (21.1.14, 21.4.X, 21.5.6 are all showing
the symptom).
Three handles are left over for each pop.
What happens if you do
(delete-process (open-network-stream "POP" (get-buffer-create "*pop*")
mailhost 110))
Do you see the handle count go up?
Thanks
andy
8189
days inactive
8191
days old
15 comments
4 participants
participants (4)
-
Adrian Aichner -
Andy Piper -
Andy Piper -
David M. Karr