10:28 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'm running virtuawin 2.5 as my virtual window manager. If
I start XEmacs and switch to another window, the text is displayed but
the frame is frozen, however buttons work (like [x] in the upper right
corner).
If I remember to set XEmacs to sticky (carries the window over to next
window), XEmacs works just fine.
I haven't found any other apps that behave this way, so I'm pretty
sure it isn not virtuawin causing the effect.
Thanks!
Kevin
================================================================
System Info to help track down your bug:
---------------------------------------
OS version:
Microsoft Windows 2000 [Version 5.00.2195]
OS: Windows_NT
XEmacs 21.4.6 \"Common Lisp (Windows)\" configured for `i586-pc-win32'.
Building XEmacs in \"f:\\xemacs\\xemacs-21.4\\nt\".
Using compiler \"cl -nologo -W3 -Od -Zi -ML\".
Installing XEmacs in \"c:\\Program Files\\XEmacs\\XEmacs-21.4.6\".
Package path is
\"~\\.xemacs;;c:\\cygwin\\usr\\local\\lib\\xemacs\\site-packages;c:\\cygwin\\usr\\local\\lib\\xemacs\\xemacs-packages\".
Compiling in support for Microsoft Windows native GUI.
Compiling in support for XPM images.
Compiling in support for GIF images.
Compiling in support for PNG images.
Compiling in support for TIFF images.
Compiling in support for JPEG images.
Compiling in support for X-Face message headers.
Compiling in support for toolbars.
Compiling in support for dialogs.
Compiling in support for widgets.
Compiling in support for native sounds.
Compiling in fast dired implementation.
Using minimal tagbits.
Using indexed lrecord implementation.
Using portable dumper.
Compiling in extra debug checks. XEmacs will be slow!
Load-Path Lisp Shadows:
----------------------
nil
Installed XEmacs Packages:
-------------------------
((zenirc:version 1.11 :type regular)
(xslt-process :version 1.05 :type regular)
(xemacs-devel :version 1.38 :type single-file)
(xemacs-base :version 1.56 :type regular)
(w3 :version 1.2 :type regular)
(vm :version 7.0 :type regular)
(viper :version 1.29 :type regular)
(view-process :version 1.11 :type regular)
(vhdl :version 1.13 :type regular)
(vc-cc :version 1.18 :type regular)
(vc :version 1.29 :type regular)
(tramp :version 1.0 :type regular)
(tpu :version 1.12 :type regular)
(tooltalk :version 1.13 :type regular)
(tm :version 1.29 :type regular)
(time :version 1.11 :type regular)
(textools :version 1.12 :type regular)
(text-modes :version 1.32 :type single-file)
(texinfo :version 1.2 :type regular)
(supercite :version 1.18 :type regular)
(strokes :version 1.08 :type regular)
(speedbar :version 1.21 :type regular)
(sounds-wav :version 1.1 :type regular)
(sounds-au :version 1.1 :type regular)
(slider :version 1.13 :type regular)
(sh-script :version 1.13 :type regular)
(sgml :version 1.08 :type regular)
(semantic :version 1.1 :type regular)
(scheme :version 1.11 :type regular)
(rmail :version 1.12 :type regular)
(reftex :version 1.23 :type regular)
(psgml :version 1.23 :type regular)
(ps-print-nomule :version 1.05 :type regular)
(prog-modes
:version
1
.44
:type
single-file)
(pcomplete :version 1.01 :type regular)
(pcl-cvs :version 1.55 :type regular)
(pc :version 1.2 :type single-file)
(os-utils :version 1.25 :type single-file)
(net-utils :version 1.23 :type single-file)
(misc-games :version 1.15 :type single-file)
(mine :version 1.14 :type regular)
(mh-e :version 1.13 :type regular)
(mew :version 1.14 :type regular)
(mailcrypt :version 2.09 :type regular)
(mail-lib :version 1.4 :type regular)
(jde :version 1.31 :type regular)
(ispell :version 1.23 :type regular)
(ilisp :version 1.19 :type regular)
(igrep :version 1.08 :type regular)
(idlwave :version 1.23 :type regular)
(hm--html-menus :version 1.16 :type regular)
(gnus :version 1.57 :type regular)
(gnats :version 1.12 :type regular)
(games :version 1.13 :type regular)
(fsf-compat :version 1.09 :type single-file)
(frame-icon :version 1.09 :type regular)
(forms :version 1.13 :type regular)
(footnote :version 1.13 :type regular)
(eudc :version 1.34 :type regular)
(eterm :version 1.13 :type regular)
(eshell :version 1.01 :type regular)
(emerge :version 1.09 :type regular)
(elib :version 1.08 :type single-file)
(eieio :version 1.01 :type regular)
(eicq :version 1.05 :type regular)
(efs :version 1.26 :type regular)
(edt :version 1.12 :type regular)
(edit-utils :version 1.73 :type single-file)
(ediff :version 1.33 :type regular)
(edebug :version 1.14 :type regular)
(dired :version 1.11 :type regular)
(dictionary :version 1.05 :type regular)
(debug :version 1.14 :type regular)
(crisp :version 1.12 :type regular)
(cookie :version 1.13 :type regular)
(clearcase :version 1.0 :type regular)
(cc-mode :version 1.26 :type regular)
(calendar :version 1.17 :type regular)
(calc :version 1.17 :type regular)
(c-support :version 1.16 :type single-file)
(build :version 1.03 :type regular)
(bbdb :version 1.16 :type regular)
(auctex :version 1.28 :type regular)
(apel :version 1.2 :type regular)
(ada :version 1.1 :type regular)
(Sun :version 1.13 :type regular))
Features:
--------
(mail-abbrevs xemacsbug shadow sendmail rfc822 font disp-table paren
blink-paren scroll-in-place rsz-minibuf func-menu crypt crypt++
completer efs-cu efs-x19.15 efs-fnh efs-ovwrt efs-auto dired-faces
dired-xemacs dired gnuserv pending-del php-mode regexp-opt font-lock
speedbar sb-image dframe assoc cc-mode cc-align cc-cmds cc-engine
cc-styles cc-langs cc-vars wid-edit cus-face cc-menus imenu cc-defs
recent-files filladapt zenirc-autoloads xslt-process-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 sh-script-autoloads sgml-autoloads semantic-autoloads
scheme-autoloads rmail-autoloads reftex-autoloads psgml-autoloads
ps-print-nomule-autoloads prog-modes-autoloads pcomplete-autoloads
pcl-cvs-autoloads pc-autoloads os-utils-autoloads net-utils-autoloads
misc-games-autoloads mine-autoloads mh-e-autoloads mew-autoloads
mailcrypt-autoloads mail-lib-autoloads jde-autoloads ispell-autoloads
ilisp-autoloads igrep-autoloads idlwave-autoloads
hm--html-menus-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 toolbar native-sound scrollbar
network-streams subprocesses menu-accelerator-support menubar md5
xemacs gutter tiff png gif jpeg xface xpm xbm lisp-float-type
windows-nt dragdrop-api dialog devices window-system base64)
Recent keystrokes:
-----------------
ESC x r e o BS p o r t - e m TAB RET
Recent messages (most recent first):
-----------------------------------
Loading xemacsbug...done
Loading xemacsbug...
Loading font...done
Loading font...
Paren mode is sexp
Loading paren...done
Loading paren...
Loading rsz-minibuf...done
Loading rsz-minibuf...
Loading gnuserv...done
Loading gnuserv...
Loading sounds...done
Loading sounds...
Loading sound...done
Loading sound...
Loading pending-del...done
Loading pending-del...
Loading php-mode-101...done
Loading php-mode-101...
Loading cus-face...done
1:04 a.m.
>>>> "jkm" == jkm <jkm(a)patriot.net>
writes:
jkm> This bug report will be sent to the XEmacs Development Team,
jkm> not to your local site managers!!
jkm> Please write in English, because the XEmacs maintainers do not have
jkm> translators to read other languages for them.
jkm> I'm running virtuawin 2.5 as my virtual window manager. If
jkm> I start XEmacs and switch to another window, the text is displayed but
jkm> the frame is frozen, however buttons work (like [x] in the upper right
jkm> corner).
jkm> If I remember to set XEmacs to sticky (carries the window over to next
jkm> window), XEmacs works just fine.
jkm> I haven't found any other apps that behave this way, so I'm pretty
jkm> sure it isn not virtuawin causing the effect.
Just as an additional check for whether virtual window managers are related to
this, it might be useful to see if using "sdesk" instead of
"virtuawin"
demonstrates the same symptom. I would assume they have a relatively similar
feature set.
You can get it from: http://tomasek.cz/sdesk/
Note the project is "closed", but it still works (at least up to win2k), and
they're still maintaining a minimal information and download page for it.
--
===================================================================
David M. Karr ; Best Consulting
dmkarr(a)earthlink.net ; Java/Unix/XML/C++/X ; BrainBench CJ12P (#12004)
8:21 a.m.
>>>> "jkm" == jkm <jkm(a)patriot.net>
writes:
jkm> This bug report will be sent to the XEmacs Development Team,
jkm> not to your local site managers!!
jkm> Please write in English, because the XEmacs maintainers do not have
jkm> translators to read other languages for them.
jkm> Please describe as succinctly as possible:
jkm> - What happened.
jkm> - What you thought should have happened.
jkm> - Precisely what you were doing at the time.
jkm> Please also include any C or lisp back-traces that you may have.
jkm> ================================================================
jkm> Dear Bug Team!
jkm> I'm running virtuawin 2.5 as my virtual window manager. If I
jkm> start XEmacs and switch to another window, the text is
jkm> displayed but the frame is frozen, however buttons work (like
jkm> [x] in the upper right corner).
Hi jkm,
I have installed virtuawin 2.5 under
ver
Microsoft Windows 2000 [Version 5.00.2195]
but cannot reproduce your problem.
Please describe as succinctly as possible:
- What happened.
- What you thought should have happened.
- Precisely what you were doing at the time.
Please describe an exact minimal set of operations which exposes the
problem.
Best regards,
Adrian
jkm> If I remember to set XEmacs to sticky (carries the window
jkm> over to next window), XEmacs works just fine.
jkm> I haven't found any other apps that behave this way, so I'm
jkm> pretty sure it isn not virtuawin causing the effect.
jkm> Thanks!
jkm> Kevin
jkm> ================================================================
jkm> System Info to help track down your bug:
jkm> ---------------------------------------
jkm> OS version:
jkm> Microsoft Windows 2000 [Version 5.00.2195]
jkm> OS: Windows_NT
jkm> XEmacs 21.4.6 \"Common Lisp (Windows)\" configured for
`i586-pc-win32'.
jkm> Building XEmacs in \"f:\\xemacs\\xemacs-21.4\\nt\".
jkm> Using compiler \"cl -nologo -W3 -Od -Zi -ML\".
jkm> Installing XEmacs in \"c:\\Program
Files\\XEmacs\\XEmacs-21.4.6\".
jkm> Package path is
jkm>
\"~\\.xemacs;;c:\\cygwin\\usr\\local\\lib\\xemacs\\site-packages;c:\\cygwin\\usr\\local\\lib\\xemacs\\xemacs-packages\".
jkm> Compiling in support for Microsoft Windows native GUI.
jkm> Compiling in support for XPM images.
jkm> Compiling in support for GIF images.
jkm> Compiling in support for PNG images.
jkm> Compiling in support for TIFF images.
jkm> Compiling in support for JPEG images.
jkm> Compiling in support for X-Face message headers.
jkm> Compiling in support for toolbars.
jkm> Compiling in support for dialogs.
jkm> Compiling in support for widgets.
jkm> Compiling in support for native sounds.
jkm> Compiling in fast dired implementation.
jkm> Using minimal tagbits.
jkm> Using indexed lrecord implementation.
jkm> Using portable dumper.
jkm> Compiling in extra debug checks. XEmacs will be slow!
jkm> Load-Path Lisp Shadows:
jkm> ----------------------
jkm> nil
jkm> Installed XEmacs Packages:
jkm> -------------------------
jkm> ((zenirc:version 1.11 :type regular)
jkm> (xslt-process :version 1.05 :type regular)
jkm> (xemacs-devel :version 1.38 :type single-file)
jkm> (xemacs-base :version 1.56 :type regular)
jkm> (w3 :version 1.2 :type regular)
jkm> (vm :version 7.0 :type regular)
jkm> (viper :version 1.29 :type regular)
jkm> (view-process :version 1.11 :type regular)
jkm> (vhdl :version 1.13 :type regular)
jkm> (vc-cc :version 1.18 :type regular)
jkm> (vc :version 1.29 :type regular)
jkm> (tramp :version 1.0 :type regular)
jkm> (tpu :version 1.12 :type regular)
jkm> (tooltalk :version 1.13 :type regular)
jkm> (tm :version 1.29 :type regular)
jkm> (time :version 1.11 :type regular)
jkm> (textools :version 1.12 :type regular)
jkm> (text-modes :version 1.32 :type single-file)
jkm> (texinfo :version 1.2 :type regular)
jkm> (supercite :version 1.18 :type regular)
jkm> (strokes :version 1.08 :type regular)
jkm> (speedbar :version 1.21 :type regular)
jkm> (sounds-wav :version 1.1 :type regular)
jkm> (sounds-au :version 1.1 :type regular)
jkm> (slider :version 1.13 :type regular)
jkm> (sh-script :version 1.13 :type regular)
jkm> (sgml :version 1.08 :type regular)
jkm> (semantic :version 1.1 :type regular)
jkm> (scheme :version 1.11 :type regular)
jkm> (rmail :version 1.12 :type regular)
jkm> (reftex :version 1.23 :type regular)
jkm> (psgml :version 1.23 :type regular)
jkm> (ps-print-nomule :version 1.05 :type regular)
jkm> (prog-modes
jkm> :version
jkm> 1
jkm> .44
jkm> :type
jkm> single-file)
jkm> (pcomplete :version 1.01 :type regular)
jkm> (pcl-cvs :version 1.55 :type regular)
jkm> (pc :version 1.2 :type single-file)
jkm> (os-utils :version 1.25 :type single-file)
jkm> (net-utils :version 1.23 :type single-file)
jkm> (misc-games :version 1.15 :type single-file)
jkm> (mine :version 1.14 :type regular)
jkm> (mh-e :version 1.13 :type regular)
jkm> (mew :version 1.14 :type regular)
jkm> (mailcrypt :version 2.09 :type regular)
jkm> (mail-lib :version 1.4 :type regular)
jkm> (jde :version 1.31 :type regular)
jkm> (ispell :version 1.23 :type regular)
jkm> (ilisp :version 1.19 :type regular)
jkm> (igrep :version 1.08 :type regular)
jkm> (idlwave :version 1.23 :type regular)
jkm> (hm--html-menus :version 1.16 :type regular)
jkm> (gnus :version 1.57 :type regular)
jkm> (gnats :version 1.12 :type regular)
jkm> (games :version 1.13 :type regular)
jkm> (fsf-compat :version 1.09 :type single-file)
jkm> (frame-icon :version 1.09 :type regular)
jkm> (forms :version 1.13 :type regular)
jkm> (footnote :version 1.13 :type regular)
jkm> (eudc :version 1.34 :type regular)
jkm> (eterm :version 1.13 :type regular)
jkm> (eshell :version 1.01 :type regular)
jkm> (emerge :version 1.09 :type regular)
jkm> (elib :version 1.08 :type single-file)
jkm> (eieio :version 1.01 :type regular)
jkm> (eicq :version 1.05 :type regular)
jkm> (efs :version 1.26 :type regular)
jkm> (edt :version 1.12 :type regular)
jkm> (edit-utils :version 1.73 :type single-file)
jkm> (ediff :version 1.33 :type regular)
jkm> (edebug :version 1.14 :type regular)
jkm> (dired :version 1.11 :type regular)
jkm> (dictionary :version 1.05 :type regular)
jkm> (debug :version 1.14 :type regular)
jkm> (crisp :version 1.12 :type regular)
jkm> (cookie :version 1.13 :type regular)
jkm> (clearcase :version 1.0 :type regular)
jkm> (cc-mode :version 1.26 :type regular)
jkm> (calendar :version 1.17 :type regular)
jkm> (calc :version 1.17 :type regular)
jkm> (c-support :version 1.16 :type single-file)
jkm> (build :version 1.03 :type regular)
jkm> (bbdb :version 1.16 :type regular)
jkm> (auctex :version 1.28 :type regular)
jkm> (apel :version 1.2 :type regular)
jkm> (ada :version 1.1 :type regular)
jkm> (Sun :version 1.13 :type regular))
jkm> Features:
jkm> --------
jkm> (mail-abbrevs xemacsbug shadow sendmail rfc822 font disp-table paren
jkm> blink-paren scroll-in-place rsz-minibuf func-menu crypt crypt++
jkm> completer efs-cu efs-x19.15 efs-fnh efs-ovwrt efs-auto dired-faces
jkm> dired-xemacs dired gnuserv pending-del php-mode regexp-opt font-lock
jkm> speedbar sb-image dframe assoc cc-mode cc-align cc-cmds cc-engine
jkm> cc-styles cc-langs cc-vars wid-edit cus-face cc-menus imenu cc-defs
jkm> recent-files filladapt zenirc-autoloads xslt-process-autoloads
jkm> xemacs-devel-autoloads xemacs-base-autoloads w3-autoloads vm-autoloads
jkm> viper-autoloads view-process-autoloads vhdl-autoloads vc-cc-autoloads
jkm> vc-autoloads tramp-autoloads tpu-autoloads tooltalk-autoloads
jkm> tm-autoloads time-autoloads textools-autoloads text-modes-autoloads
jkm> texinfo-autoloads supercite-autoloads strokes-autoloads
jkm> speedbar-autoloads sounds-wav-autoloads sounds-au-autoloads
jkm> slider-autoloads sh-script-autoloads sgml-autoloads semantic-autoloads
jkm> scheme-autoloads rmail-autoloads reftex-autoloads psgml-autoloads
jkm> ps-print-nomule-autoloads prog-modes-autoloads pcomplete-autoloads
jkm> pcl-cvs-autoloads pc-autoloads os-utils-autoloads net-utils-autoloads
jkm> misc-games-autoloads mine-autoloads mh-e-autoloads mew-autoloads
jkm> mailcrypt-autoloads mail-lib-autoloads jde-autoloads ispell-autoloads
jkm> ilisp-autoloads igrep-autoloads idlwave-autoloads
jkm> hm--html-menus-autoloads gnus-autoloads gnats-autoloads
jkm> games-autoloads fsf-compat-autoloads frame-icon-autoloads
jkm> forms-autoloads footnote-autoloads eudc-autoloads eterm-autoloads
jkm> eshell-autoloads emerge-autoloads elib-autoloads eieio-autoloads
jkm> eicq-autoloads efs-autoloads edt-autoloads edit-utils-autoloads
jkm> ediff-autoloads edebug-autoloads dired-autoloads dictionary-autoloads
jkm> debug-autoloads crisp-autoloads cookie-autoloads clearcase-autoloads
jkm> cc-mode-autoloads calendar-autoloads calc-autoloads
jkm> c-support-autoloads build-autoloads bbdb-autoloads auctex-autoloads
jkm> apel-autoloads ada-autoloads Sun-autoloads lisp-autoloads loadhist
jkm> auto-show fontl-hooks code-cmds gutter-items menubar-items x-menubar
jkm> dragdrop mode-motion mouse itimer auto-save lisp-mode easymenu
jkm> iso8859-1 page buff-menu lib-complete help-nomule cus-file derived
jkm> frame text-props obsolete cus-start custom widget cl-extra mini-cl cl
jkm> cl-19 packages backquote very-early-lisp file-coding
jkm> mswindows-scrollbars mswindows toolbar native-sound scrollbar
jkm> network-streams subprocesses menu-accelerator-support menubar md5
jkm> xemacs gutter tiff png gif jpeg xface xpm xbm lisp-float-type
jkm> windows-nt dragdrop-api dialog devices window-system base64)
jkm> Recent keystrokes:
jkm> -----------------
jkm> ESC x r e o BS p o r t - e m TAB RET
jkm> Recent messages (most recent first):
jkm> -----------------------------------
jkm> Loading xemacsbug...done
jkm> Loading xemacsbug...
jkm> Loading font...done
jkm> Loading font...
jkm> Paren mode is sexp
jkm> Loading paren...done
jkm> Loading paren...
jkm> Loading rsz-minibuf...done
jkm> Loading rsz-minibuf...
jkm> Loading gnuserv...done
jkm> Loading gnuserv...
jkm> Loading sounds...done
jkm> Loading sounds...
jkm> Loading sound...done
jkm> Loading sound...
jkm> Loading pending-del...done
jkm> Loading pending-del...
jkm> Loading php-mode-101...done
jkm> Loading php-mode-101...
jkm> Loading cus-face...done
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
9:36 a.m.
>>>> "APA" == Adrian Aichner
<Adrian.Aichner(a)t-online.de> writes:
jkm, our configurations differ as follows:
You use a build of the Windows branch, I use mainstream 21.4.6.
Your binary was compiled with cl ... -ML, mine with cl ... -MDd.
I use "system malloc" and "DLL version of C runtime", you don't.
Could one of these be the culprit?
I use
Refresh_after_warp# 0
in
c:\Program Files\VirtuaWin\vwconfig.AichnerAd.cfg
What's your setting?
What virtuawin config changes have you made against the installation default?
Best regards,
Adrian
--- jkm Mon Jan 14 10:23:36 2002
+++ adrian Mon Jan 14 10:23:36 2002
＠＠ -3,13 +3,12 ＠＠
Microsoft Windows 2000 [Version 5.00.2195]
OS: Windows_NT
-XEmacs 21.4.6 \"Common Lisp (Windows)\" configured for `i586-pc-win32'.
+XEmacs 21.4.6 \"Common Lisp\" configured for `i586-pc-win32'.
- Building XEmacs in \"f:\\xemacs\\xemacs-21.4\\nt\".
- Using compiler \"cl -nologo -W3 -Od -Zi -ML\".
+ Building XEmacs in \"c:\\Hacking\\xemacs\\xemacs-21.4\\nt\".
+ Using compiler \"cl -nologo -W3 -Od -Zi -MDd\".
Installing XEmacs in \"c:\\Program Files\\XEmacs\\XEmacs-21.4.6\".
- Package path is
-\"~\\.xemacs;;c:\\cygwin\\usr\\local\\lib\\xemacs\\site-packages;c:\\cygwin\\usr\\local\\lib\\xemacs\\xemacs-packages\".
+ Package path is \"~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program
Files\\XEmacs\\xemacs-packages\".
Compiling in support for Microsoft Windows native GUI.
Compiling in support for XPM images.
Compiling in support for GIF images.
＠＠ -25,4 +24,6 ＠＠
Using minimal tagbits.
Using indexed lrecord implementation.
Using portable dumper.
+ Using system malloc.
+ Using DLL version of C runtime library
Compiling in extra debug checks. XEmacs will be slow!
>>>> "jkm" == jkm <jkm(a)patriot.net>
writes:
jkm> This bug report will be sent to the XEmacs Development Team,
jkm> not to your local site managers!!
jkm> Please write in English, because the XEmacs maintainers do not have
jkm> translators to read other languages for them.
jkm> Please describe as succinctly as possible:
jkm> - What happened.
jkm> - What you thought should have happened.
jkm> - Precisely what you were doing at the time.
jkm> Please also include any C or lisp back-traces that you may have.
jkm> ================================================================
jkm> Dear Bug Team!
jkm> I'm running virtuawin 2.5 as my virtual window manager. If I
jkm> start XEmacs and switch to another window, the text is
jkm> displayed but the frame is frozen, however buttons work (like
jkm> [x] in the upper right corner).
APA> Hi jkm,
APA> I have installed virtuawin 2.5 under
APA> ver
APA> Microsoft Windows 2000 [Version 5.00.2195]
APA> but cannot reproduce your problem.
APA> Please describe as succinctly as possible:
APA> - What happened.
APA> - What you thought should have happened.
APA> - Precisely what you were doing at the time.
APA> Please describe an exact minimal set of operations which exposes the
APA> problem.
APA> Best regards,
APA> Adrian
<lines deleted by Adrian>
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
9:50 a.m.
>>>> "APA" == Adrian Aichner
<adrian(a)xemacs.org> writes:
>>>> "APA" == Adrian Aichner
<Adrian.Aichner(a)t-online.de> writes:
APA> jkm, our configurations
differ as follows:
APA> You use a build of the Windows branch, I use mainstream 21.4.6.
Argh! Only the Windows branch has my deiconify patch which Andy
suspects to cause the problem.
I have tried 21.5-b4 now (which I have handy and has the patch also)
and it sure has the problem!
The evidence is crushing :-(
Refresh_after_warp# 1
does not help either.
I don't need any further info, can reproduce now.
More this evening,
Adrian
APA> Your binary was compiled with cl ... -ML, mine with cl ... -MDd.
APA> I use "system malloc" and "DLL version of C runtime", you
don't.
APA> Could one of these be the culprit?
APA> I use
APA> Refresh_after_warp# 0
APA> in
APA> c:\Program Files\VirtuaWin\vwconfig.AichnerAd.cfg
APA> What's your setting?
APA> What virtuawin config changes have you made against the installation default?
APA> Best regards,
APA> Adrian
APA> --- jkm Mon Jan 14 10:23:36 2002
APA> +++ adrian Mon Jan 14 10:23:36 2002
APA> ＠＠ -3,13 +3,12 ＠＠
APA> Microsoft Windows 2000 [Version 5.00.2195]
APA> OS: Windows_NT
APA> -XEmacs 21.4.6 \"Common Lisp (Windows)\" configured for
`i586-pc-win32'.
APA> +XEmacs 21.4.6 \"Common Lisp\" configured for `i586-pc-win32'.
APA> - Building XEmacs in \"f:\\xemacs\\xemacs-21.4\\nt\".
APA> - Using compiler \"cl -nologo -W3 -Od -Zi -ML\".
APA> + Building XEmacs in \"c:\\Hacking\\xemacs\\xemacs-21.4\\nt\".
APA> + Using compiler \"cl -nologo -W3 -Od -Zi -MDd\".
APA> Installing XEmacs in \"c:\\Program
Files\\XEmacs\\XEmacs-21.4.6\".
APA> - Package path is
APA>
-\"~\\.xemacs;;c:\\cygwin\\usr\\local\\lib\\xemacs\\site-packages;c:\\cygwin\\usr\\local\\lib\\xemacs\\xemacs-packages\".
APA> + Package path is \"~\\.xemacs;;c:\\Program
Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages\".
APA> Compiling in support for Microsoft Windows native GUI.
APA> Compiling in support for XPM images.
APA> Compiling in support for GIF images.
APA> ＠＠ -25,4 +24,6 ＠＠
APA> Using minimal tagbits.
APA> Using indexed lrecord implementation.
APA> Using portable dumper.
APA> + Using system malloc.
APA> + Using DLL version of C runtime library
APA> Compiling in extra debug checks. XEmacs will be slow!
>>>> "jkm" == jkm <jkm(a)patriot.net>
writes:
jkm> This bug report will be sent to the XEmacs Development Team,
jkm> not to your local site managers!!
jkm> Please write in English, because the XEmacs maintainers do not have
jkm> translators to read other languages for them.
jkm> Please describe as succinctly as possible:
jkm> - What happened.
jkm> - What you thought should have happened.
jkm> - Precisely what you were doing at the time.
jkm> Please also include any C or lisp back-traces that you may have.
jkm> ================================================================
jkm> Dear Bug Team!
jkm> I'm running virtuawin 2.5 as my virtual window manager. If I
jkm> start XEmacs and switch to another window, the text is
jkm> displayed but the frame is frozen, however buttons work (like
jkm> [x] in the upper right corner).
APA> Hi jkm,
APA> I have installed virtuawin 2.5 under
APA> ver
APA> Microsoft Windows 2000 [Version 5.00.2195]
APA> but cannot reproduce your problem.
APA> Please describe as succinctly as possible:
APA> - What happened.
APA> - What you thought should have happened.
APA> - Precisely what you were doing at the time.
APA> Please describe an exact minimal set of operations which exposes the
APA> problem.
APA> Best regards,
APA> Adrian
APA> <lines deleted by Adrian>
APA> --
APA> Adrian Aichner
APA> mailto:adrian＠xemacs.org
APA> http://www.xemacs.org/
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
10:46 a.m.
Adrian, I don't think your iconifcation fix was in the mainline.
andy
At 10:36 AM 1/14/2002 +0100, Adrian Aichner wrote:
>>>>> "APA" == Adrian Aichner
<Adrian.Aichner(a)t-online.de> writes:
jkm, our configurations differ as follows:
You use a build of the Windows branch, I use mainstream 21.4.6.
Your binary was compiled with cl ... -ML, mine with cl ... -MDd.
I use "system malloc" and "DLL version of C runtime", you don't.
Could one of these be the culprit?
I use
Refresh_after_warp# 0
in
c:\Program Files\VirtuaWin\vwconfig.AichnerAd.cfg
What's your setting?
What virtuawin config changes have you made against the installation default?
Best regards,
Adrian
--- jkm Mon Jan 14 10:23:36 2002
+++ adrian Mon Jan 14 10:23:36 2002
＠＠ -3,13 +3,12 ＠＠
Microsoft Windows 2000 [Version 5.00.2195]
OS: Windows_NT
-XEmacs 21.4.6 \"Common Lisp (Windows)\" configured for `i586-pc-win32'.
+XEmacs 21.4.6 \"Common Lisp\" configured for `i586-pc-win32'.
- Building XEmacs in \"f:\\xemacs\\xemacs-21.4\\nt\".
- Using compiler \"cl -nologo -W3 -Od -Zi -ML\".
+ Building XEmacs in \"c:\\Hacking\\xemacs\\xemacs-21.4\\nt\".
+ Using compiler \"cl -nologo -W3 -Od -Zi -MDd\".
Installing XEmacs in \"c:\\Program Files\\XEmacs\\XEmacs-21.4.6\".
- Package path is
-\"~\\.xemacs;;c:\\cygwin\\usr\\local\\lib\\xemacs\\site-packages;c:\\cygwin\\usr\\local\\lib\\xemacs\\xemacs-packages\".
+ Package path is \"~\\.xemacs;;c:\\Program
Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\xemacs-packages\".
Compiling in support for Microsoft Windows native GUI.
Compiling in support for XPM images.
Compiling in support for GIF images.
＠＠ -25,4 +24,6 ＠＠
Using minimal tagbits.
Using indexed lrecord implementation.
Using portable dumper.
+ Using system malloc.
+ Using DLL version of C runtime library
Compiling in extra debug checks. XEmacs will be slow!
>>>>> "jkm" == jkm <jkm(a)patriot.net> writes:
jkm> This bug report will be sent to the XEmacs Development Team,
jkm> not to your local site managers!!
jkm> Please write in English, because the XEmacs maintainers do not have
jkm> translators to read other languages for them.
jkm> Please describe as succinctly as possible:
jkm> - What happened.
jkm> - What you thought should have happened.
jkm> - Precisely what you were doing at the time.
jkm> Please also include any C or lisp back-traces that you may have.
jkm> ================================================================
jkm> Dear Bug Team!
jkm> I'm running virtuawin 2.5 as my virtual window manager. If I
jkm> start XEmacs and switch to another window, the text is
jkm> displayed but the frame is frozen, however buttons work (like
jkm> [x] in the upper right corner).
APA> Hi jkm,
APA> I have installed virtuawin 2.5 under
APA> ver
APA> Microsoft Windows 2000 [Version 5.00.2195]
APA> but cannot reproduce your problem.
APA> Please describe as succinctly as possible:
APA> - What happened.
APA> - What you thought should have happened.
APA> - Precisely what you were doing at the time.
APA> Please describe an exact minimal set of operations which exposes the
APA> problem.
APA> Best regards,
APA> Adrian
<lines deleted by Adrian>
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
8:29 p.m.
New subject: [Adrian.Aichner@t-online.de (Adrian Aichner)] [A5R4] [PATCH] r21-4-6-windows: mswindows_wnd_proc to handle WM_SHOWWINDOW (for virtuawin)
Please test this fix.
Adrian
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
10:01 a.m.
Hello Andy, David, jkm, All!
I need your help!
Could some of you who can build native XEmacs on windows and are
willing to test it under virtuawin please test it with following patch
applied?
http://list-archive.xemacs.org/xemacs-patches/200201/msg00101.html
virtuawin is available for free from
http://tucows.netsurf.de/system/adnload/217486_91449.html
Thanks for your help.
I have seen no problems with my fix during testing with and without
virtuawin and will commit it to 21.5 later today.
Best regards,
Adrian
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
3:31 p.m.
>>>> "APA" == Adrian Aichner
<adrian(a)xemacs.org> writes:
APA> Hello Andy, David, jkm, All!
APA> I need your help!
APA> Could some of you who can build native XEmacs on windows and are
APA> willing to test it under virtuawin please test it with following patch
APA> applied?
APA> http://list-archive.xemacs.org/xemacs-patches/200201/msg00101.html
APA> virtuawin is available for free from
APA> http://tucows.netsurf.de/system/adnload/217486_91449.html
APA> Thanks for your help.
APA> I have seen no problems with my fix during testing with and without
APA> virtuawin and will commit it to 21.5 later today.
By "native", do you mean "non-cygwin"? I only use the Cygwin version.
In any
case, I haven't set up to build either native or Cygwin XEmacs on Windows.
That would be a good thing to do, but I doubt I could get this done and tested
today. Failing that, it would be good if I knew when an installable release of
this would be available.
--
===================================================================
David M. Karr ; Java/J2EE/XML/Unix/C++
dmkarr(a)earthlink.net ; BrainBench CJ12P (#12004)
2:28 p.m.
At 07:31 AM 1/18/2002 -0800, David M. Karr wrote:
By "native", do you mean "non-cygwin"? I only use
the Cygwin version. In any
case, I haven't set up to build either native or Cygwin XEmacs on Windows.
That would be a good thing to do, but I doubt I could get this done and tested
today. Failing that, it would be good if I knew when an installable
release of
this would be available.
I'm back in the US and online once again. A binary release should show up
sometime this coming week.
andy
3:11 p.m.
>>>> "Andy" == Andy Piper <andyp(a)bea.com>
writes:
Andy> At 07:31 AM 1/18/2002 -0800, David M. Karr wrote:
> By "native", do you mean "non-cygwin"? I
only use the Cygwin version. In any
> case, I haven't set up to build either native or Cygwin XEmacs on Windows.
> That would be a good thing to do, but I doubt I could get this done and tested
> today. Failing that, it would be good if I knew when an installable
> release of
> this would be available.
Andy> I'm back in the US and online once again. A binary release
Andy> should show up sometime this coming week.
Great!
Welcome back!
I finally got around to submit some Call Stack and Variable
information for my recent XEmacs crashes of native W2K 21.4.6 XEmacs
including this patch to xemacs-winnt.
All crashes are unrelated to my patch AFAICT.
Didn't you already have a fix for earlier crahes related to failed
assertions for
/* If you hit this, rewrite the offending API call to occur after GC,
using register_post_gc_action(). */
assert (!gc_in_progress);
in
mswindows_wnd_proc(HWND__ * 0x00100148, unsigned int 257, unsigned int 81, long
-1072693247) line 2075 + 41 bytes
and/or
/* This will assert if handle being waited for becomes abandoned.
Not the case currently tho */
assert ((!badly_p && active == WAIT_TIMEOUT) ||
(active >= WAIT_OBJECT_0 &&
active <= WAIT_OBJECT_0 + mswindows_waitable_count));
in
mswindows_need_event(int 0) line 1519 + 52 bytes
?
Andy> andy
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
4:10 p.m.
At 04:11 PM 1/19/2002 +0100, Adrian Aichner wrote:
>>>>> "Andy" == Andy Piper
<andyp(a)bea.com> writes:
Andy> At 07:31 AM 1/18/2002 -0800, David M. Karr wrote:
>> By "native", do you mean "non-cygwin"? I only use the
Cygwin
version. In any
>> case, I haven't set up to build either native or Cygwin XEmacs on
Windows.
>> That would be a good thing to do, but I doubt I could get this
done and tested
>> today. Failing that, it would be good if I knew when an installable
>> release of
>> this would be available.
Andy> I'm back in the US and online once again. A binary release
Andy> should show up sometime this coming week.
Great!
Welcome back!
I finally got around to submit some Call Stack and Variable
information for my recent XEmacs crashes of native W2K 21.4.6 XEmacs
including this patch to xemacs-winnt.
All crashes are unrelated to my patch AFAICT.
Didn't you already have a fix for earlier crahes related to failed
assertions for
/* If you hit this, rewrite the offending API call to occur after GC,
using register_post_gc_action(). */
assert (!gc_in_progress);
in
mswindows_wnd_proc(HWND__ * 0x00100148, unsigned int 257, unsigned int 81,
long -1072693247) line 2075 + 41 bytes
If you see these you need to figure out what is causing events to be
processed while GC'ing.
and/or
/* This will assert if handle being waited for becomes abandoned.
Not the case currently tho */
assert ((!badly_p && active == WAIT_TIMEOUT) ||
(active >= WAIT_OBJECT_0 &&
active <= WAIT_OBJECT_0 + mswindows_waitable_count));
in
mswindows_need_event(int 0) line 1519 + 52 bytes
No, this has been around for ages, but the binary dist does not have debug
on so it ends up being harmless. However, if we could actually fix it that
would be great.
andy
10:53 a.m.
>>>> "Andy" == Andy Piper <andyp(a)bea.com>
writes:
Andy> At 04:11 PM 1/19/2002 +0100, Adrian Aichner wrote:
>> >>>> "Andy" == Andy
Piper <andyp(a)bea.com> writes:
>>
Andy> At 07:31 AM 1/18/2002 -0800, David M. Karr wrote:
> >> By "native", do you mean
"non-cygwin"? I only use the Cygwin
> >> version. In any
> >> case, I haven't set up to build either native or
Cygwin
> >> XEmacs on Windows.
> >> That would be a good thing to do, but I doubt I could
get
> >> this done and tested
> >> today. Failing that, it would be good if I knew when an
installable
> >> release of
>
> >> this would be available.
>
Andy> I'm back in the US and online once again. A binary release
Andy> should show up sometime this coming week.
>
> Great!
>
> Welcome back!
>
> I finally got around to submit some Call Stack and Variable
> information for my recent XEmacs crashes of native W2K 21.4.6 XEmacs
> including this patch to xemacs-winnt.
>
> All crashes are unrelated to my patch AFAICT.
>
> Didn't you already have a fix for earlier crahes related to failed
> assertions for
>
> /* If you hit this, rewrite the offending API call to occur after GC,
> using register_post_gc_action(). */
> assert (!gc_in_progress);
> in
> mswindows_wnd_proc(HWND__ * 0x00100148, unsigned int 257, unsigned
> int 81, long -1072693247) line 2075 + 41 bytes
Andy> If you see these you need to figure out what is causing events to be
Andy> processed while GC'ing.
Right, got another one of this and am already in the debugger -- what
would you say is the offending API or how would I find out?
Would it possibly be update_window_scrollbars?
Actually, mark_redisplay () has a comment by Ben which might be worth
worrying about:
void
mark_redisplay (void)
{
Lisp_Object frmcons, devcons, concons;
FRAME_LOOP_NO_BREAK (frmcons, devcons, concons)
{
struct frame *f = XFRAME (XCAR (frmcons));
/* #### urk! this does tons o' crap, such as creating lots of
structs, doing window system actions, etc. we DO NOT want to
be doing this -- marking should never change any state.
i think we can just delete this. --ben */
update_frame_window_mirror (f);
mark_window_mirror (f->root_mirror);
mark_gutters (f);
}
}
What to do?
Excerpt from complete Call Stack below:
update_window_scrollbars(window * 0x08925cc0, window_mirror *
0x022ae898, int 0, int 0) line 294 + 46 bytes
update_mirror_internal(long 143809728, window_mirror * 0x022ae898) line 390 + 26 bytes
update_frame_window_mirror(frame * 0x022ecdc8) line 462 + 22 bytes
mark_redisplay() line 7107 + 9 bytes
garbage_collect_1() line 3483
Here's the complete
Call Stack:
NTDLL! 77fa018c()
mswindows_wnd_proc(HWND__ * 0x001d0396, unsigned int 132, unsigned int 0, long 21693196)
line 2080 + 41 bytes
USER32! 77e12e98()
USER32! 77e139a3()
USER32! 77e1395f()
NTDLL! 77fa032f()
USER32! 77e1569d()
mswindows_drain_windows_queue() line 1286 + 18 bytes
emacs_mswindows_quit_p() line 3553
event_stream_quit_p() line 597
check_quit() line 514
unbind_to_hairy(int 35) line 4967
unbind_to(int 35, long 20613800) line 4952 + 174 bytes
dfc_convert_to_external_format(int 0, dfc_conversion_data * 0x0082b890, long 21742968, int
0, dfc_conversion_data * 0x0082b89c) line 1948 + 16 bytes
std_handle_out_va(_iobuf * 0x10261868, const char * 0x012daea4, char * 0x0082d8e0) line
188 + 99 bytes
stderr_out(const char * 0x012daea4) line 211 + 55 bytes
assert_failed(const char * 0x011cd5dc, int 2080, const char * 0x011cd5cc) line 3309 + 22
bytes
mswindows_wnd_proc(HWND__ * 0x001d0396, unsigned int 20, unsigned int 973147397, long 0)
line 2080 + 41 bytes
USER32! 77e12e98()
USER32! 77e139a3()
USER32! 77e1395f()
NTDLL! 77fa032f()
update_window_scrollbars(window * 0x08925cc0, window_mirror * 0x022ae898, int 0, int 0)
line 294 + 46 bytes
update_mirror_internal(long 143809728, window_mirror * 0x022ae898) line 390 + 26 bytes
update_frame_window_mirror(frame * 0x022ecdc8) line 462 + 22 bytes
mark_redisplay() line 7107 + 9 bytes
garbage_collect_1() line 3483
Ffuncall(int 2, long * 0x0082e4fc) line 3479
execute_optimized_program(const unsigned char * 0x013f6078, int 4, long * 0x0149ae60) line
746 + 16 bytes
funcall_compiled_function(long 21739132, int 3, long * 0x0082e7d8) line 518 + 53 bytes
Ffuncall(int 4, long * 0x0082e7d4) line 3563 + 17 bytes
execute_optimized_program(const unsigned char * 0x013f60d0, int 5, long * 0x0149aea0) line
746 + 16 bytes
funcall_compiled_function(long 21739160, int 3, long * 0x0082eab4) line 518 + 53 bytes
Ffuncall(int 4, long * 0x0082eab0) line 3563 + 17 bytes
execute_optimized_program(const unsigned char * 0x013f6108, int 5, long * 0x0149aed4) line
746 + 16 bytes
funcall_compiled_function(long 21739188, int 3, long * 0x0082ed90) line 518 + 53 bytes
Ffuncall(int 4, long * 0x0082ed8c) line 3563 + 17 bytes
execute_optimized_program(const unsigned char * 0x013f6168, int 5, long * 0x0149af14) line
746 + 16 bytes
funcall_compiled_function(long 21739216, int 2, long * 0x0082f074) line 518 + 53 bytes
Ffuncall(int 3, long * 0x0082f070) line 3563 + 17 bytes
execute_optimized_program(const unsigned char * 0x013f61c0, int 8, long * 0x0149af6c) line
746 + 16 bytes
funcall_compiled_function(long 21739272, int 5, long * 0x0082f354) line 518 + 53 bytes
Ffuncall(int 6, long * 0x0082f350) line 3563 + 17 bytes
execute_optimized_program(const unsigned char * 0x013f6230, int 6, long * 0x0149afc4) line
746 + 16 bytes
funcall_compiled_function(long 21739300, int 6, long * 0x0082f634) line 518 + 53 bytes
Ffuncall(int 7, long * 0x0082f630) line 3563 + 17 bytes
execute_optimized_program(const unsigned char * 0x013f6278, int 7, long * 0x0149b008) line
746 + 16 bytes
funcall_compiled_function(long 21739328, int 3, long * 0x0082f918) line 518 + 53 bytes
Ffuncall(int 4, long * 0x0082f914) line 3563 + 17 bytes
execute_optimized_program(const unsigned char * 0x0289ad18, int 15, long * 0x014905d8)
line 746 + 16 bytes
funcall_compiled_function(long 21723088, int 1, long * 0x0082fc88) line 518 + 53 bytes
Ffuncall(int 2, long * 0x0082fc84) line 3563 + 17 bytes
run_hook_with_args_in_buffer(buffer * 0x00e6ad80, int 2, long * 0x0082fc84, int 0) line
4020 + 13 bytes
run_hook_with_args(int 2, long * 0x0082fc84, int 0) line 4033 + 23 bytes
va_run_hook_with_args(long 20536976, int 1) line 4104 + 18 bytes
redisplay_frame(frame * 0x022ecdc8, int 0) line 6299 + 17 bytes
redisplay_device(device * 0x0225cdc8, int 1) line 6476 + 11 bytes
redisplay_without_hooks() line 6563 + 11 bytes
redisplay() line 6626
Fnext_event(long 51194052, long 20613800) line 2179
Fcommand_loop_1() line 574 + 16 bytes
command_loop_1(long 20613800) line 495
condition_case_1(long 20613440, long (long)* 0x01051d06 command_loop_1(long), long
20613800, long (long, long)* 0x01051720 cmd_error(long, long), long 20613800) line 1651 +
7 bytes
command_loop_3() line 256 + 35 bytes
command_loop_2(long 20613800) line 269
internal_catch(long 20441216, long (long)* 0x01051870 command_loop_2(long), long 20613800,
int * volatile 0x00000000) line 1317 + 7 bytes
initial_command_loop(long 20613800) line 305 + 25 bytes
STACK_TRACE_EYE_CATCHER(int 1, char * * 0x00e62e68, char * * 0x00e62f50, int 0) line 2355
main(int 1, char * * 0x00e62e68, char * * 0x00e62f50) line 2723
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e97d08()
> and/or
> /* This will assert if handle being waited for becomes abandoned.
> Not the case currently tho */
> assert ((!badly_p && active == WAIT_TIMEOUT) ||
> (active >= WAIT_OBJECT_0 &&
> active <= WAIT_OBJECT_0 + mswindows_waitable_count));
> in
> mswindows_need_event(int 0) line 1519 + 52 bytes
Andy> No, this has been around for ages, but the binary dist does not have
Andy> debug on so it ends up being harmless. However, if we could actually
Andy> fix it that would be great.
Andy> andy
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
3:05 p.m.
I think we should do what Ben says and try commenting out the call to
update_window_scrollbars. The alternative would be to do this before we go
into GC. We could do this by having a run_pre_gc_actions which does the
same as run_post_gc_actions and then does the update there. I don't see
anyway of surviving update_window_scrollbars actually inside GC.
andy
At 11:53 AM 1/20/2002 +0100, Adrian Aichner wrote:
>>>>> "Andy" == Andy Piper
<andyp(a)bea.com> writes:
Andy> At 04:11 PM 1/19/2002 +0100, Adrian Aichner wrote:
>> >>>>> "Andy" == Andy Piper <andyp(a)bea.com>
writes:
>>
Andy> At 07:31 AM 1/18/2002 -0800, David M. Karr wrote:
>> >> By "native", do you mean "non-cygwin"? I only
use the Cygwin
>> >> version. In any
>> >> case, I haven't set up to build either native or Cygwin
>> >> XEmacs on Windows.
>> >> That would be a good thing to do, but I doubt I could get
>> >> this done and tested
>> >> today. Failing that, it would be good if I knew when an
installable
>> >> release of
>>
>> >> this would be available.
>>
Andy> I'm back in the US and online once again. A binary release
Andy> should show up sometime this coming week.
>>
>> Great!
>>
>> Welcome back!
>>
>> I finally got around to submit some Call Stack and Variable
>> information for my recent XEmacs crashes of native W2K 21.4.6 XEmacs
>> including this patch to xemacs-winnt.
>>
>> All crashes are unrelated to my patch AFAICT.
>>
>> Didn't you already have a fix for earlier crahes related to failed
>> assertions for
>>
>> /* If you hit this, rewrite the offending API call to occur after GC,
>> using register_post_gc_action(). */
>> assert (!gc_in_progress);
>> in
>> mswindows_wnd_proc(HWND__ * 0x00100148, unsigned int 257, unsigned
>> int 81, long -1072693247) line 2075 + 41 bytes
Andy> If you see these you need to figure out what is causing events
to be
Andy> processed while GC'ing.
Right, got another one of this and am already in the debugger -- what
would you say is the offending API or how would I find out?
Would it possibly be update_window_scrollbars?
Actually, mark_redisplay () has a comment by Ben which might be worth
worrying about:
void
mark_redisplay (void)
{
Lisp_Object frmcons, devcons, concons;
FRAME_LOOP_NO_BREAK (frmcons, devcons, concons)
{
struct frame *f = XFRAME (XCAR (frmcons));
/* #### urk! this does tons o' crap, such as creating lots of
structs, doing window system actions, etc. we DO NOT want to
be doing this -- marking should never change any state.
i think we can just delete this. --ben */
update_frame_window_mirror (f);
mark_window_mirror (f->root_mirror);
mark_gutters (f);
}
}
What to do?
Excerpt from complete Call Stack below:
> update_window_scrollbars(window * 0x08925cc0, window_mirror *
0x022ae898, int 0, int 0) line 294 + 46 bytes
> update_mirror_internal(long 143809728, window_mirror * 0x022ae898) line
390 + 26 bytes
> update_frame_window_mirror(frame * 0x022ecdc8) line 462 + 22 bytes
> mark_redisplay() line 7107 + 9 bytes
> garbage_collect_1() line 3483
Here's the complete
Call Stack:
NTDLL! 77fa018c()
mswindows_wnd_proc(HWND__ * 0x001d0396, unsigned int 132, unsigned int 0,
long 21693196) line 2080 + 41 bytes
USER32! 77e12e98()
USER32! 77e139a3()
USER32! 77e1395f()
NTDLL! 77fa032f()
USER32! 77e1569d()
mswindows_drain_windows_queue() line 1286 + 18 bytes
emacs_mswindows_quit_p() line 3553
event_stream_quit_p() line 597
check_quit() line 514
unbind_to_hairy(int 35) line 4967
unbind_to(int 35, long 20613800) line 4952 + 174 bytes
dfc_convert_to_external_format(int 0, dfc_conversion_data * 0x0082b890,
long 21742968, int 0, dfc_conversion_data * 0x0082b89c) line 1948 + 16 bytes
std_handle_out_va(_iobuf * 0x10261868, const char * 0x012daea4, char *
0x0082d8e0) line 188 + 99 bytes
stderr_out(const char * 0x012daea4) line 211 + 55 bytes
assert_failed(const char * 0x011cd5dc, int 2080, const char * 0x011cd5cc)
line 3309 + 22 bytes
mswindows_wnd_proc(HWND__ * 0x001d0396, unsigned int 20, unsigned int
973147397, long 0) line 2080 + 41 bytes
USER32! 77e12e98()
USER32! 77e139a3()
USER32! 77e1395f()
NTDLL! 77fa032f()
update_window_scrollbars(window * 0x08925cc0, window_mirror * 0x022ae898,
int 0, int 0) line 294 + 46 bytes
update_mirror_internal(long 143809728, window_mirror * 0x022ae898) line
390 + 26 bytes
update_frame_window_mirror(frame * 0x022ecdc8) line 462 + 22 bytes
mark_redisplay() line 7107 + 9 bytes
garbage_collect_1() line 3483
Ffuncall(int 2, long * 0x0082e4fc) line 3479
execute_optimized_program(const unsigned char * 0x013f6078, int 4, long *
0x0149ae60) line 746 + 16 bytes
funcall_compiled_function(long 21739132, int 3, long * 0x0082e7d8) line
518 + 53 bytes
Ffuncall(int 4, long * 0x0082e7d4) line 3563 + 17 bytes
execute_optimized_program(const unsigned char * 0x013f60d0, int 5, long *
0x0149aea0) line 746 + 16 bytes
funcall_compiled_function(long 21739160, int 3, long * 0x0082eab4) line
518 + 53 bytes
Ffuncall(int 4, long * 0x0082eab0) line 3563 + 17 bytes
execute_optimized_program(const unsigned char * 0x013f6108, int 5, long *
0x0149aed4) line 746 + 16 bytes
funcall_compiled_function(long 21739188, int 3, long * 0x0082ed90) line
518 + 53 bytes
Ffuncall(int 4, long * 0x0082ed8c) line 3563 + 17 bytes
execute_optimized_program(const unsigned char * 0x013f6168, int 5, long *
0x0149af14) line 746 + 16 bytes
funcall_compiled_function(long 21739216, int 2, long * 0x0082f074) line
518 + 53 bytes
Ffuncall(int 3, long * 0x0082f070) line 3563 + 17 bytes
execute_optimized_program(const unsigned char * 0x013f61c0, int 8, long *
0x0149af6c) line 746 + 16 bytes
funcall_compiled_function(long 21739272, int 5, long * 0x0082f354) line
518 + 53 bytes
Ffuncall(int 6, long * 0x0082f350) line 3563 + 17 bytes
execute_optimized_program(const unsigned char * 0x013f6230, int 6, long *
0x0149afc4) line 746 + 16 bytes
funcall_compiled_function(long 21739300, int 6, long * 0x0082f634) line
518 + 53 bytes
Ffuncall(int 7, long * 0x0082f630) line 3563 + 17 bytes
execute_optimized_program(const unsigned char * 0x013f6278, int 7, long *
0x0149b008) line 746 + 16 bytes
funcall_compiled_function(long 21739328, int 3, long * 0x0082f918) line
518 + 53 bytes
Ffuncall(int 4, long * 0x0082f914) line 3563 + 17 bytes
execute_optimized_program(const unsigned char * 0x0289ad18, int 15, long *
0x014905d8) line 746 + 16 bytes
funcall_compiled_function(long 21723088, int 1, long * 0x0082fc88) line
518 + 53 bytes
Ffuncall(int 2, long * 0x0082fc84) line 3563 + 17 bytes
run_hook_with_args_in_buffer(buffer * 0x00e6ad80, int 2, long *
0x0082fc84, int 0) line 4020 + 13 bytes
run_hook_with_args(int 2, long * 0x0082fc84, int 0) line 4033 + 23 bytes
va_run_hook_with_args(long 20536976, int 1) line 4104 + 18 bytes
redisplay_frame(frame * 0x022ecdc8, int 0) line 6299 + 17 bytes
redisplay_device(device * 0x0225cdc8, int 1) line 6476 + 11 bytes
redisplay_without_hooks() line 6563 + 11 bytes
redisplay() line 6626
Fnext_event(long 51194052, long 20613800) line 2179
Fcommand_loop_1() line 574 + 16 bytes
command_loop_1(long 20613800) line 495
condition_case_1(long 20613440, long (long)* 0x01051d06
command_loop_1(long), long 20613800, long (long, long)* 0x01051720
cmd_error(long, long), long 20613800) line 1651 + 7 bytes
command_loop_3() line 256 + 35 bytes
command_loop_2(long 20613800) line 269
internal_catch(long 20441216, long (long)* 0x01051870
command_loop_2(long), long 20613800, int * volatile 0x00000000) line 1317
+ 7 bytes
initial_command_loop(long 20613800) line 305 + 25 bytes
STACK_TRACE_EYE_CATCHER(int 1, char * * 0x00e62e68, char * * 0x00e62f50,
int 0) line 2355
main(int 1, char * * 0x00e62e68, char * * 0x00e62f50) line 2723
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e97d08()
>> and/or
>> /* This will assert if handle being waited for becomes abandoned.
>> Not the case currently tho */
>> assert ((!badly_p && active == WAIT_TIMEOUT) ||
>> (active >= WAIT_OBJECT_0 &&
>> active <= WAIT_OBJECT_0 + mswindows_waitable_count));
>> in
>> mswindows_need_event(int 0) line 1519 + 52 bytes
Andy> No, this has been around for ages, but the binary dist does not
have
Andy> debug on so it ends up being harmless. However, if we could
actually
Andy> fix it that would be great.
Andy> andy
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
4:08 p.m.
>>>> "Andy" == Andy Piper <andyp(a)bea.com>
writes:
Andy> I think we should do what Ben says and try commenting out
Andy> the call to update_window_scrollbars. The alternative would
Something like this?
Index: window.c
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/window.c,v
retrieving revision 1.52.2.1.2.3
diff -u -u -r1.52.2.1.2.3 window.c
--- window.c 2001/12/01 05:54:21 1.52.2.1.2.3
+++ window.c 2002/01/20 15:52:49
＠＠ -386,9 +386,6 ＠＠
mir->current_display_lines = Dynarr_new (display_line);
mir->desired_display_lines = Dynarr_new (display_line);
-#ifdef HAVE_SCROLLBARS
- update_window_scrollbars (XWINDOW (win), mir, 0, 0);
-#endif
mir->buffer = NULL;
}
Andy> be to do this before we go into GC. We could do this by
Andy> having a run_pre_gc_actions which does the same as
Andy> run_post_gc_actions and then does the update there. I don't
I wonder why the implementer of run_post_gc_actions has not
implemented run_pre_gc_actions as well. Could you think of a reason
why this would not be a good idea?
What would we set up for register_pre_gc_action?
Just a function doing
#ifdef HAVE_SCROLLBARS
update_window_scrollbars (XWINDOW (win), mir, 0, 0);
#endif
perhaps?
Adrian
Andy> see anyway of surviving update_window_scrollbars actually
Andy> inside GC.
Andy> andy
<lines deleted by Adrian>
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
5:41 p.m.
>>>> "Andy" == Andy Piper <andyp(a)bea.com>
writes:
Andy> At 04:11 PM 1/19/2002 +0100, Adrian Aichner wrote:
>> >>>> "Andy" == Andy
Piper <andyp(a)bea.com> writes:
>>
Andy> At 07:31 AM 1/18/2002 -0800, David M. Karr wrote:
> >> By "native", do you mean
"non-cygwin"? I only use the Cygwin
> >> version. In any
> >> case, I haven't set up to build either native or
Cygwin
> >> XEmacs on Windows.
> >> That would be a good thing to do, but I doubt I could
get
> >> this done and tested
> >> today. Failing that, it would be good if I knew when an
installable
> >> release of
>
> >> this would be available.
>
Andy> I'm back in the US and online once again. A binary release
Andy> should show up sometime this coming week.
>
> Great!
>
> Welcome back!
>
> I finally got around to submit some Call Stack and Variable
> information for my recent XEmacs crashes of native W2K 21.4.6 XEmacs
> including this patch to xemacs-winnt.
>
> All crashes are unrelated to my patch AFAICT.
>
> Didn't you already have a fix for earlier crahes related to failed
> assertions for
>
> /* If you hit this, rewrite the offending API call to occur after GC,
> using register_post_gc_action(). */
> assert (!gc_in_progress);
> in
> mswindows_wnd_proc(HWND__ * 0x00100148, unsigned int 257, unsigned
> int 81, long -1072693247) line 2075 + 41 bytes
Andy> If you see these you need to figure out what is causing events to be
Andy> processed while GC'ing.
> and/or
> /* This will assert if handle being waited for becomes abandoned.
> Not the case currently tho */
> assert ((!badly_p && active == WAIT_TIMEOUT) ||
> (active >= WAIT_OBJECT_0 &&
> active <= WAIT_OBJECT_0 + mswindows_waitable_count));
> in
> mswindows_need_event(int 0) line 1519 + 52 bytes
Andy> No, this has been around for ages, but the binary dist does not have
Andy> debug on so it ends up being harmless. However, if we could actually
Andy> fix it that would be great.
I think the assert needs to take into account that
MsgWaitForMultipleObjects may fail, in which case active will be -1.
All my crashes here in fact are of this nature.
Instead of adding (active == -1) to the assert expression, how about this:
Index: event-msw.c
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/event-msw.c,v
retrieving revision 1.47.2.4.2.4
diff -u -u -r1.47.2.4.2.4 event-msw.c
--- event-msw.c 2001/11/24 23:14:52 1.47.2.4.2.4
+++ event-msw.c 2002/01/20 17:24:36
＠＠ -1512,11 +1512,16 ＠＠
FALSE, badly_p ? INFINITE : 0,
what_events);
- /* This will assert if handle being waited for becomes abandoned.
- Not the case currently tho */
- assert ((!badly_p && active == WAIT_TIMEOUT) ||
- (active >= WAIT_OBJECT_0 &&
- active <= WAIT_OBJECT_0 + mswindows_waitable_count));
+ if (active == -1) {
+ mswindows_output_last_error ("MsgWaitForMultipleObjects");
+ }
+ else {
+ /* This will assert if handle being waited for becomes abandoned.
+ Not the case currently tho */
+ assert ((!badly_p && active == WAIT_TIMEOUT) ||
+ (active >= WAIT_OBJECT_0 &&
+ active <= WAIT_OBJECT_0 + mswindows_waitable_count));
+ }
if (active == WAIT_TIMEOUT)
{
Andy> andy
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
5:19 p.m.
At 05:08 PM 1/20/02 +0100, Adrian Aichner wrote:
>>>>> "Andy" == Andy Piper
<andyp(a)bea.com> writes:
Andy> I think we should do what Ben says and try commenting out
Andy> the call to update_window_scrollbars. The alternative would
Something like this?
Index: window.c
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/window.c,v
retrieving revision 1.52.2.1.2.3
diff -u -u -r1.52.2.1.2.3 window.c
--- window.c 2001/12/01 05:54:21 1.52.2.1.2.3
+++ window.c 2002/01/20 15:52:49
＠＠ -386,9 +386,6 ＠＠
mir->current_display_lines = Dynarr_new (display_line);
mir->desired_display_lines = Dynarr_new (display_line);
-#ifdef HAVE_SCROLLBARS
- update_window_scrollbars (XWINDOW (win), mir, 0, 0);
-#endif
mir->buffer = NULL;
}
No I mean in mark_redisplay(). We should update the window mirrors before
going into GC.
Andy> be to do this before we go into GC. We could do this by
Andy> having a run_pre_gc_actions which does the same as
Andy> run_post_gc_actions and then does the update there. I don't
I wonder why the implementer of run_post_gc_actions has not
implemented run_pre_gc_actions as well. Could you think of a reason
why this would not be a good idea?
The reason Ben did not do this is because run_post_gc_actions is supposed
to be used for cleaning up things that cannot be deleted in GC (e.g. GUI
windows). Before GC is run this condition does not exist. However, there is
no reason I can think of why this isn't a good idea.
What would we set up for register_pre_gc_action?
Just a function doing
#ifdef HAVE_SCROLLBARS
update_window_scrollbars (XWINDOW (win), mir, 0, 0);
#endif
perhaps?
Right, but looping over all frames as per mark_redisplay()
andy
9:26 a.m.
>>>> "Andy" == Andy Piper <andyp(a)bea.com>
writes:
Andy> At 05:08 PM 1/20/02 +0100, Adrian Aichner wrote:
>> >>>> "Andy" == Andy
Piper <andyp(a)bea.com> writes:
>>
Andy> I think we should do what Ben says and try commenting out
Andy> the call to update_window_scrollbars. The alternative would
>
> Something like this?
>
> Index: window.c
> ===================================================================
> RCS file: /pack/xemacscvs/XEmacs/xemacs/src/window.c,v
> retrieving revision 1.52.2.1.2.3
> diff -u -u -r1.52.2.1.2.3 window.c
> --- window.c 2001/12/01 05:54:21 1.52.2.1.2.3
> +++ window.c 2002/01/20 15:52:49
> ＠＠ -386,9 +386,6 ＠＠
mir-> current_display_lines = Dynarr_new
(display_line);
mir-> desired_display_lines = Dynarr_new (display_line);
>
> -#ifdef HAVE_SCROLLBARS
> - update_window_scrollbars (XWINDOW (win), mir, 0, 0);
> -#endif
mir-> buffer = NULL;
> }
Andy> No I mean in mark_redisplay(). We should update the window mirrors
Andy> before going into GC.
Andy> be to do this before we go into GC. We could do this by
Andy> having a run_pre_gc_actions which does the same as
Andy> run_post_gc_actions and then does the update there. I don't
>
> I wonder why the implementer of run_post_gc_actions has not
> implemented run_pre_gc_actions as well. Could you think of a reason
> why this would not be a good idea?
Andy> The reason Ben did not do this is because run_post_gc_actions is
Andy> supposed to be used for cleaning up things that cannot be deleted in
Andy> GC (e.g. GUI windows). Before GC is run this condition does not
Andy> exist. However, there is no reason I can think of why this isn't a
Andy> good idea.
I guess run_pre_gc_actions looks like a winner?
Will take a shot at this tonite.
> What would we set up for register_pre_gc_action?
>
> Just a function doing
>
> #ifdef HAVE_SCROLLBARS
> update_window_scrollbars (XWINDOW (win), mir, 0, 0);
> #endif
>
> perhaps?
Andy> Right, but looping over all frames as per mark_redisplay()
OK.
Andy> andy
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
10:22 p.m.
>>>> "Andy" == Andy Piper <andyp(a)bea.com>
writes:
Andy> At 05:08 PM 1/20/02 +0100, Adrian Aichner wrote:
>> >>>> "Andy" == Andy
Piper <andyp(a)bea.com> writes:
>>
Andy> I think we should do what Ben says and try commenting out
Andy> the call to update_window_scrollbars. The alternative would
>
> Something like this?
>
> Index: window.c
> ===================================================================
> RCS file: /pack/xemacscvs/XEmacs/xemacs/src/window.c,v
> retrieving revision 1.52.2.1.2.3
> diff -u -u -r1.52.2.1.2.3 window.c
> --- window.c 2001/12/01 05:54:21 1.52.2.1.2.3
> +++ window.c 2002/01/20 15:52:49
> ＠＠ -386,9 +386,6 ＠＠
mir-> current_display_lines = Dynarr_new
(display_line);
mir-> desired_display_lines = Dynarr_new (display_line);
>
> -#ifdef HAVE_SCROLLBARS
> - update_window_scrollbars (XWINDOW (win), mir, 0, 0);
> -#endif
mir-> buffer = NULL;
> }
Andy> No I mean in mark_redisplay(). We should update the window mirrors
Andy> before going into GC.
Perhaps I misunderstood, but:
Once we are in mark_redisplay, GC is already in progress. It's too
late to do something pre-gc.
Where would I put the
register_pre_gc_action (...);
call which should do the following:
FRAME_LOOP_NO_BREAK (frmcons, devcons, concons)
{
struct frame *f = XFRAME (XCAR (frmcons));
/* #### urk! this does tons o' crap, such as creating lots of
structs, doing window system actions, etc. we DO NOT want to
be doing this -- marking should never change any state.
i think we can just delete this. --ben */
/*
Prompted by Ben's note above and following advice from Andy I
am trying to do this via newly implemented pre_gc_action --
Adrian.
*/
update_frame_window_mirror, f);
}
post_gc actions are set up like this:
if (gc_in_progress)
/* #### way bogus! need to remove the offending call.
see mark_redisplay(). */
register_post_gc_action (unshow_that_mofo,
(void *) SCROLLBAR_MSW_HANDLE (sb));
but we can't do the same for pre:
if (gc_in_progress)
register_post_gc_action (...);
couldn't possibly work, right :-)
It would only do it previous to the next GC.
Are you suggesting the following should also be reworked to pre_gc?
static void
mswindows_release_scrollbar_instance (struct scrollbar_instance *sb)
{
if (gc_in_progress)
/* #### way bogus! need to remove the offending call.
see mark_redisplay(). */
register_post_gc_action (unshow_that_mofo,
(void *) SCROLLBAR_MSW_HANDLE (sb));
else
ShowScrollBar (SCROLLBAR_MSW_HANDLE (sb), SB_CTL, 0);
SCROLLBAR_MSW_SIZE (sb) = 0;
}
Ready for a vacation,
Adrian
Andy> be to do this before we go into GC. We could do this by
Andy> having a run_pre_gc_actions which does the same as
Andy> run_post_gc_actions and then does the update there. I don't
>
> I wonder why the implementer of run_post_gc_actions has not
> implemented run_pre_gc_actions as well. Could you think of a reason
> why this would not be a good idea?
Andy> The reason Ben did not do this is because run_post_gc_actions is
Andy> supposed to be used for cleaning up things that cannot be deleted in
Andy> GC (e.g. GUI windows). Before GC is run this condition does not
Andy> exist. However, there is no reason I can think of why this isn't a
Andy> good idea.
> What would we set up for register_pre_gc_action?
>
> Just a function doing
>
> #ifdef HAVE_SCROLLBARS
> update_window_scrollbars (XWINDOW (win), mir, 0, 0);
> #endif
>
> perhaps?
Andy> Right, but looping over all frames as per mark_redisplay()
Andy> andy
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
3:34 a.m.
please try following my comment. just delete the line. don't do anything
else. no need to update window mirrors prior to gc.
Adrian Aichner wrote:
>>>>> "Andy" == Andy Piper <andyp(a)bea.com> writes:
Andy> At 05:08 PM 1/20/02 +0100, Adrian Aichner wrote:
>> >>>>> "Andy" == Andy Piper <andyp(a)bea.com>
writes:
>>
Andy> I think we should do what Ben says and try commenting out
Andy> the call to update_window_scrollbars. The alternative would
>>
>> Something like this?
>>
>> Index: window.c
>> ===================================================================
>> RCS file: /pack/xemacscvs/XEmacs/xemacs/src/window.c,v
>> retrieving revision 1.52.2.1.2.3
>> diff -u -u -r1.52.2.1.2.3 window.c
>> --- window.c 2001/12/01 05:54:21 1.52.2.1.2.3
>> +++ window.c 2002/01/20 15:52:49
>> ＠＠ -386,9 +386,6 ＠＠
mir-> current_display_lines = Dynarr_new (display_line);
mir-> desired_display_lines = Dynarr_new (display_line);
>>
>> -#ifdef HAVE_SCROLLBARS
>> - update_window_scrollbars (XWINDOW (win), mir, 0, 0);
>> -#endif
mir-> buffer = NULL;
>> }
Andy> No I mean in mark_redisplay(). We should update the window mirrors
Andy> before going into GC.
Perhaps I misunderstood, but:
Once we are in mark_redisplay, GC is already in progress. It's too
late to do something pre-gc.
Where would I put the
register_pre_gc_action (...);
call which should do the following:
FRAME_LOOP_NO_BREAK (frmcons, devcons, concons)
{
struct frame *f = XFRAME (XCAR (frmcons));
/* #### urk! this does tons o' crap, such as creating lots of
structs, doing window system actions, etc. we DO NOT want to
be doing this -- marking should never change any state.
i think we can just delete this. --ben */
/*
Prompted by Ben's note above and following advice from Andy I
am trying to do this via newly implemented pre_gc_action --
Adrian.
*/
update_frame_window_mirror, f);
}
post_gc actions are set up like this:
if (gc_in_progress)
/* #### way bogus! need to remove the offending call.
see mark_redisplay(). */
register_post_gc_action (unshow_that_mofo,
(void *) SCROLLBAR_MSW_HANDLE (sb));
but we can't do the same for pre:
if (gc_in_progress)
register_post_gc_action (...);
couldn't possibly work, right :-)
It would only do it previous to the next GC.
Are you suggesting the following should also be reworked to pre_gc?
static void
mswindows_release_scrollbar_instance (struct scrollbar_instance *sb)
{
if (gc_in_progress)
/* #### way bogus! need to remove the offending call.
see mark_redisplay(). */
register_post_gc_action (unshow_that_mofo,
(void *) SCROLLBAR_MSW_HANDLE (sb));
else
ShowScrollBar (SCROLLBAR_MSW_HANDLE (sb), SB_CTL, 0);
SCROLLBAR_MSW_SIZE (sb) = 0;
}
Ready for a vacation,
Adrian
Andy> be to do this before we go into GC. We could do this by
Andy> having a run_pre_gc_actions which does the same as
Andy> run_post_gc_actions and then does the update there. I don't
>>
>> I wonder why the implementer of run_post_gc_actions has not
>> implemented run_pre_gc_actions as well. Could you think of a reason
>> why this would not be a good idea?
Andy> The reason Ben did not do this is because run_post_gc_actions is
Andy> supposed to be used for cleaning up things that cannot be deleted in
Andy> GC (e.g. GUI windows). Before GC is run this condition does not
Andy> exist. However, there is no reason I can think of why this isn't a
Andy> good idea.
>> What would we set up for register_pre_gc_action?
>>
>> Just a function doing
>>
>> #ifdef HAVE_SCROLLBARS
>> update_window_scrollbars (XWINDOW (win), mir, 0, 0);
>> #endif
>>
>> perhaps?
Andy> Right, but looping over all frames as per mark_redisplay()
Andy> andy
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
12:33 p.m.
>>>> "Ben" == Ben Wing <ben(a)xemacs.org>
writes:
Ben> please try following my comment. just delete the line.
Ben> don't do anything else. no need to update window mirrors
No problem if it's the right thing to do.
I was wondering why you didn't do it and assumed it couldn't possibly
be that simple.
Ben> prior to gc.
Do you agree also, Andy?
Ben> Adrian Aichner wrote:
>
> >>>>> "Andy" == Andy Piper <andyp(a)bea.com> writes:
>
Andy> At 05:08 PM 1/20/02 +0100, Adrian Aichner wrote:
> >> >>>>> "Andy" == Andy Piper
<andyp(a)bea.com> writes:
> >>
Andy> I think we should do what Ben says and try commenting
out
Andy> the call to update_window_scrollbars. The alternative would
> >>
> >> Something like this?
> >>
> >> Index: window.c
> >> ===================================================================
> >> RCS file: /pack/xemacscvs/XEmacs/xemacs/src/window.c,v
> >> retrieving revision 1.52.2.1.2.3
> >> diff -u -u -r1.52.2.1.2.3 window.c
> >> --- window.c 2001/12/01 05:54:21 1.52.2.1.2.3
> >> +++ window.c 2002/01/20 15:52:49
> >> ＠＠ -386,9 +386,6 ＠＠
mir-> current_display_lines = Dynarr_new
(display_line);
mir-> desired_display_lines = Dynarr_new (display_line);
> >>
> >> -#ifdef HAVE_SCROLLBARS
> >> - update_window_scrollbars (XWINDOW (win), mir, 0, 0);
> >> -#endif
mir-> buffer = NULL;
> >> }
>
Andy> No I mean in mark_redisplay(). We should update the window
mirrors
Andy> before going into GC.
>
> Perhaps I misunderstood, but:
>
> Once we are in mark_redisplay, GC is already in progress. It's too
> late to do something pre-gc.
>
> Where would I put the
> register_pre_gc_action (...);
> call which should do the following:
>
> FRAME_LOOP_NO_BREAK (frmcons, devcons, concons)
> {
> struct frame *f = XFRAME (XCAR (frmcons));
> /* #### urk! this does tons o' crap, such as creating lots of
> structs, doing window system actions, etc. we DO NOT want to
> be doing this -- marking should never change any state.
> i think we can just delete this. --ben */
> /*
> Prompted by Ben's note above and following advice from Andy I
> am trying to do this via newly implemented pre_gc_action --
> Adrian.
> */
> update_frame_window_mirror, f);
> }
>
> post_gc actions are set up like this:
>
> if (gc_in_progress)
> /* #### way bogus! need to remove the offending call.
> see mark_redisplay(). */
> register_post_gc_action (unshow_that_mofo,
> (void *) SCROLLBAR_MSW_HANDLE (sb));
>
> but we can't do the same for pre:
>
> if (gc_in_progress)
> register_post_gc_action (...);
> couldn't possibly work, right :-)
> It would only do it previous to the next GC.
>
> Are you suggesting the following should also be reworked to pre_gc?
>
> static void
> mswindows_release_scrollbar_instance (struct scrollbar_instance *sb)
> {
> if (gc_in_progress)
> /* #### way bogus! need to remove the offending call.
> see mark_redisplay(). */
> register_post_gc_action (unshow_that_mofo,
> (void *) SCROLLBAR_MSW_HANDLE (sb));
> else
> ShowScrollBar (SCROLLBAR_MSW_HANDLE (sb), SB_CTL, 0);
> SCROLLBAR_MSW_SIZE (sb) = 0;
> }
>
> Ready for a vacation,
>
> Adrian
>
Andy> be to do this before we go into GC. We could do this by
Andy> having a run_pre_gc_actions which does the same as
Andy> run_post_gc_actions and then does the update there. I don't
> >>
> >> I wonder why the implementer of run_post_gc_actions has not
> >> implemented run_pre_gc_actions as well. Could you think of a reason
> >> why this would not be a good idea?
>
Andy> The reason Ben did not do this is because run_post_gc_actions is
Andy> supposed to be used for cleaning up things that cannot be deleted in
Andy> GC (e.g. GUI windows). Before GC is run this condition does not
Andy> exist. However, there is no reason I can think of why this isn't a
Andy> good idea.
>
> >> What would we set up for register_pre_gc_action?
> >>
> >> Just a function doing
> >>
> >> #ifdef HAVE_SCROLLBARS
> >> update_window_scrollbars (XWINDOW (win), mir, 0, 0);
> >> #endif
> >>
> >> perhaps?
>
Andy> Right, but looping over all frames as per mark_redisplay()
>
Andy> andy
>
>> --
>> Adrian Aichner
>> mailto:adrian＠xemacs.org
>> http://www.xemacs.org/
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
5:36 p.m.
At 01:33 PM 2/4/2002 +0100, Adrian Aichner wrote:
>>>>> "Ben" == Ben Wing
<ben(a)xemacs.org> writes:
Ben> please try following my comment. just delete the line.
Ben> don't do anything else. no need to update window mirrors
No problem if it's the right thing to do.
I was wondering why you didn't do it and assumed it couldn't possibly
be that simple.
Ben> prior to gc.
Do you agree also, Andy?
Obviously neither of us know why that code was put in there in the first
place. I agree with Ben that it should be removed, however, I'm concerned
that it was put in for some weirdo edge-case crash. So go ahead - try it.
andy
7:40 p.m.
>>>> "Andy" == Andy Piper <andyp(a)bea.com>
writes:
Andy> At 01:33 PM 2/4/2002 +0100, Adrian Aichner wrote:
> >>>>> "Ben" == Ben Wing
<ben(a)xemacs.org> writes:
>
Ben> please try following my comment. just delete the line.
Ben> don't do anything else. no need to update window mirrors
>
> No problem if it's the right thing to do.
>
> I was wondering why you didn't do it and assumed it couldn't possibly
> be that simple.
>
Ben> prior to gc.
>
> Do you agree also, Andy?
Andy> Obviously neither of us know why that code was put in there
Andy> in the first place. I agree with Ben that it should be
Andy> removed, however, I'm concerned that it was put in for some
Andy> weirdo edge-case crash. So go ahead - try it.
Ben, Andy, could pre_gc_action be of use (possibly for other uses) in
the future? Andy you suggested it in the first place.
Should I just remove
+ register_pre_gc_action (update_all_frame_window_mirrors,
+ (void *) 0);
from redisplay.c instead?
Please advise,
Adrian
Andy> andy
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
2:31 p.m.
Adrian Aichner wrote:
>>>>> "Andy" == Andy Piper <andyp(a)bea.com> writes:
Andy> At 01:33 PM 2/4/2002 +0100, Adrian Aichner wrote:
>> >>>>> "Ben" == Ben Wing <ben(a)xemacs.org>
writes:
>>
Ben> please try following my comment. just delete the line.
Ben> don't do anything else. no need to update window mirrors
>>
>> No problem if it's the right thing to do.
>>
>> I was wondering why you didn't do it and assumed it couldn't
possibly
>> be that simple.
>>
Ben> prior to gc.
>>
>> Do you agree also, Andy?
Andy> Obviously neither of us know why that code was put in there
Andy> in the first place. I agree with Ben that it should be
Andy> removed, however, I'm concerned that it was put in for some
Andy> weirdo edge-case crash. So go ahead - try it.
Ben, Andy, could pre_gc_action be of use (possibly for other uses) in
the future? Andy you suggested it in the first place.
Should I just remove
+ register_pre_gc_action (update_all_frame_window_mirrors,
+ (void *) 0);
from redisplay.c instead?
yes. no point in code that has no purpose.
Please advise,
Adrian
Andy> andy
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
2:37 p.m.
i didn't remove it mostly because it was near a release or something, and i
wasn't positively sure something wouldn't break. but i do think it's correct.
i think the problem is that when chuck wrote the window mirror code he got into
the mindset of automatically updating the window mirror before any operation
that accessed it. it probably slipped his mind that marking was a special case.
[chuck -- apologies if you didn't write the code. problem is that in
mark_redisplay[], before marking the window mirrors, the code tries to update
them, which does all sorts of things, some of which turn out to be extremely
unsafe during gc, esp. under windows, where we create or delete some scrollbar
windows, triggering the one of the internal event loops. this update is
unnecessary because marking should never change state.]
Adrian Aichner wrote:
>>>>> "Ben" == Ben Wing <ben(a)xemacs.org> writes:
Ben> please try following my comment. just delete the line.
Ben> don't do anything else. no need to update window mirrors
No problem if it's the right thing to do.
I was wondering why you didn't do it and assumed it couldn't possibly
be that simple.
Ben> prior to gc.
Do you agree also, Andy?
Ben> Adrian Aichner wrote:
>>
>> >>>>> "Andy" == Andy Piper <andyp(a)bea.com>
writes:
>>
Andy> At 05:08 PM 1/20/02 +0100, Adrian Aichner wrote:
>> >> >>>>> "Andy" == Andy Piper
<andyp(a)bea.com> writes:
>> >>
Andy> I think we should do what Ben says and try commenting out
Andy> the call to update_window_scrollbars. The alternative would
>> >>
>> >> Something like this?
>> >>
>> >> Index: window.c
>> >>
===================================================================
>> >> RCS file: /pack/xemacscvs/XEmacs/xemacs/src/window.c,v
>> >> retrieving revision 1.52.2.1.2.3
>> >> diff -u -u -r1.52.2.1.2.3 window.c
>> >> --- window.c 2001/12/01 05:54:21 1.52.2.1.2.3
>> >> +++ window.c 2002/01/20 15:52:49
>> >> ＠＠ -386,9 +386,6 ＠＠
mir-> current_display_lines = Dynarr_new (display_line);
mir-> desired_display_lines = Dynarr_new (display_line);
>> >>
>> >> -#ifdef HAVE_SCROLLBARS
>> >> - update_window_scrollbars (XWINDOW (win), mir, 0, 0);
>> >> -#endif
mir-> buffer = NULL;
>> >> }
>>
Andy> No I mean in mark_redisplay(). We should update the window mirrors
Andy> before going into GC.
>>
>> Perhaps I misunderstood, but:
>>
>> Once we are in mark_redisplay, GC is already in progress. It's too
>> late to do something pre-gc.
>>
>> Where would I put the
>> register_pre_gc_action (...);
>> call which should do the following:
>>
>> FRAME_LOOP_NO_BREAK (frmcons, devcons, concons)
>> {
>> struct frame *f = XFRAME (XCAR (frmcons));
>> /* #### urk! this does tons o' crap, such as creating lots of
>> structs, doing window system actions, etc. we DO NOT want to
>> be doing this -- marking should never change any state.
>> i think we can just delete this. --ben */
>> /*
>> Prompted by Ben's note above and following advice from Andy I
>> am trying to do this via newly implemented pre_gc_action --
>> Adrian.
>> */
>> update_frame_window_mirror, f);
>> }
>>
>> post_gc actions are set up like this:
>>
>> if (gc_in_progress)
>> /* #### way bogus! need to remove the offending call.
>> see mark_redisplay(). */
>> register_post_gc_action (unshow_that_mofo,
>> (void *) SCROLLBAR_MSW_HANDLE (sb));
>>
>> but we can't do the same for pre:
>>
>> if (gc_in_progress)
>> register_post_gc_action (...);
>> couldn't possibly work, right :-)
>> It would only do it previous to the next GC.
>>
>> Are you suggesting the following should also be reworked to pre_gc?
>>
>> static void
>> mswindows_release_scrollbar_instance (struct scrollbar_instance *sb)
>> {
>> if (gc_in_progress)
>> /* #### way bogus! need to remove the offending call.
>> see mark_redisplay(). */
>> register_post_gc_action (unshow_that_mofo,
>> (void *) SCROLLBAR_MSW_HANDLE (sb));
>> else
>> ShowScrollBar (SCROLLBAR_MSW_HANDLE (sb), SB_CTL, 0);
>> SCROLLBAR_MSW_SIZE (sb) = 0;
>> }
>>
>> Ready for a vacation,
>>
>> Adrian
>>
Andy> be to do this before we go into GC. We could do this by
Andy> having a run_pre_gc_actions which does the same as
Andy> run_post_gc_actions and then does the update there. I don't
>> >>
>> >> I wonder why the implementer of run_post_gc_actions has not
>> >> implemented run_pre_gc_actions as well. Could you think of a
reason
>> >> why this would not be a good idea?
>>
Andy> The reason Ben did not do this is because run_post_gc_actions is
Andy> supposed to be used for cleaning up things that cannot be deleted in
Andy> GC (e.g. GUI windows). Before GC is run this condition does not
Andy> exist. However, there is no reason I can think of why this isn't a
Andy> good idea.
>>
>> >> What would we set up for register_pre_gc_action?
>> >>
>> >> Just a function doing
>> >>
>> >> #ifdef HAVE_SCROLLBARS
>> >> update_window_scrollbars (XWINDOW (win), mir, 0, 0);
>> >> #endif
>> >>
>> >> perhaps?
>>
Andy> Right, but looping over all frames as per mark_redisplay()
>>
Andy> andy
>>
>> --
>> Adrian Aichner
>> mailto:adrian＠xemacs.org
>> http://www.xemacs.org/
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
2:37 p.m.
At 07:37 AM 2/7/2002 -0700, Ben Wing wrote:
[chuck -- apologies if you didn't write the code. problem is that
in
mark_redisplay[], before marking the window mirrors, the code tries to update
them, which does all sorts of things, some of which turn out to be extremely
unsafe during gc, esp. under windows, where we create or delete some scrollbar
windows, triggering the one of the internal event loops. this update is
unnecessary because marking should never change state.]
I honestly have no idea any more what I did and did not write :-)
-Chuck
8118
days inactive
8145
days old
26 comments
8 participants
participants (8)
-
Adrian Aichner -
Adrian Aichner -
Andy Piper -
Ben Wing -
Ben Wing -
Chuck Thompson -
David M. Karr -
jkm＠patriot.net