> Date: Wed, 9 May 2012 20:11:59 -0400
> From: "John J. Xenakis" <hewreg@jxen...>
> Cc: jxenakis123@gmai... >
> Since I'm running 64-bit Windows, what it looks like to me is that
> emacs is using some 64-bit counter as a 32-bit or 16-bit counter
> that's cycling around to zero after several days of heavy use of
Do you have any evidence for that? Emacs is a 32-bit application, so
it cannot use any 64-bit feature on Windows, in general. It should
work on a 64-bit OS exactly as it does on a 32-bit OS.
> People using 64-bit Windows 7 should be aware of this bug, and be
> prepared for it.
Well, I recently started using 64-bit Windows 7 on my daytime job, so
I will report in a week or two ;-)
> The workaround is to close and reopen emacs (you don't have to log
> out or reboot). This is a lot harder than it sounds, with windows
> freaking out and you can't find where your emacs window is. But if
> you can bring up the task manager, you can kill emacs. What I had
> to do was to create an abort macro, assigned to keystroke
> ctl-alt-f1, that creates a quick recovery file and exits. If you do
> that, then all you have to do is remember where your emacs window
> was, click on it, and launch the abort keystroke. Once emacs exits,
> all your other application windows are ok again.
Thanks for the recipe. However, it is much better to solve the
problem, whatever it is, rather than use a fire escape from now on.
Windows 7 is going to be a mainstream platform for years, and Emacs
should be able to run on it without any major problems.
So please do this:
. "M-x report-emacs-bug RET" and describe there every detail you can
about the problem. The report will give us some information you
failed to mention, like the version of Emacs etc.
. If you are using any version older than the latest pretest of Emacs
24, v24.0.96 as of this writing, please install the latest version
and see if the problem persists. If it does, mention that in your
bug report (assuming you submit it before upgrading).
. If the problem exists in the latest pretest, try to see what Emacs
is doing when the problem happens. To that end, attach GDB to it
and show a backtrace from all of the threads.
. Finally, start a separate Emacs session running "emacs -Q", and see
if that session also causes trouble. If it doesn't try bisecting
your .emacs to see which of the optional features you use there
causes the problem.