Re: [h-e-w] Current word on binaries

Re: [h-e-w] Current word on binaries

[Harald Maier]

Harald Maier <harald@maierh.de> writes:

> "David Vanderschel" <DvdS@Austin.RR.com> writes:
>
>> On February 4 <Eric.Belpaire@equant.com> wrote in message
>> news:<mailman.1868.1075904614.928.help-gnu-emacs@gnu.org>...
>> Hello,
>>
>> I've installed the binary packages (fullbin and barebin) of emacs
>> 21.3 compiled for Windows, available at
>> http://ftp.gnu.org/gnu/emacs/windows/ The binary packages don't
>> work neither on Windows 2000, nor on Windows 98.  They crash.
>>
>> Emacs remains an outstanding editor.  Thank you for it.
>> Best regards,
>
> I tried it too and I found too that something goes wrong. 'emacs -q'
> works fine, but when I tried to load my .emacs it displays the 'Emacs
> Abort Dialog' and complains that 'A fatal error has occured!'

I did some additional tests and it looks that the problem occurs only
if emacs-21.3 is compiled with a latest cygwin gcc. I did two test
with the emacs-21.3.tar.gz from March last year and the actual tarball
from ftp.gnu.org. On both sources the same happens, so it does not
look that something has changed since the compromise of the server.
Afterwards I compiled emacs with MSVC and the result is that all works
as expected. Currently I have no clue why the problem with gcc
happens.  On my system I have also the latest cvs emacs and that is
always compiled by the cygwin gcc and it works very well. Maybe other
people have an idea why the problem occurs only on the emacs-21.3
sources. I would suggest that we change the current distribution from
a mingw compilation to a msvc compilation.

Harald

Re: [h-e-w] Current word on binaries

[Jason Rumney]

Harald Maier <harald@maierh.de> writes:

> I would suggest that we change the current distribution from a mingw
> compilation to a msvc compilation.

I will do that. It may take some time though, because I think the GNU
admins will have to delete the existing files before I can upload new
ones, and they are still busy with changes to CVS after the most
recent attack on GNU servers. Until then, please use binaries from
other sources.

Re: Current word on binaries

[Eli Zaretskii]

> From: Harald Maier <harald@maierh.de>
> Date: Sat, 14 Feb 2004 10:33:50 +0100
> >
> > I tried it too and I found too that something goes wrong. 'emacs -q'
> > works fine, but when I tried to load my .emacs it displays the 'Emacs
> > Abort Dialog' and complains that 'A fatal error has occured!'
> 
> I did some additional tests and it looks that the problem occurs only
> if emacs-21.3 is compiled with a latest cygwin gcc. I did two test
> with the emacs-21.3.tar.gz from March last year and the actual tarball
> from ftp.gnu.org. On both sources the same happens, so it does not
> look that something has changed since the compromise of the server.
> Afterwards I compiled emacs with MSVC and the result is that all works
> as expected. Currently I have no clue why the problem with gcc
> happens.

What version of GCC is the one that produces a bad binary?  What does
"gcc --version" says?

Can someone run Emacs under GDB and see where exactly does it abort?

One possible idea to check is to use lower level of optimizations when
building Emacs, like -O0 or -O1.  Can someone see if that produces a
good binary?

Re: [h-e-w] Current word on binaries

[Jason Rumney]

"Eli Zaretskii" <eliz@elta.co.il> writes:

> Can someone run Emacs under GDB and see where exactly does it abort?

I have done that. It aborts on line 1739 of bytecode.c.

#ifdef BYTE_CODE_SAFE
    error ("binding stack not balanced (serious byte compiler bug)");
#else
    abort ();
#endif

Since it is deep within the byte code interpreter it is difficult to
find what happened to get get the binding stack in that state.

Re: [h-e-w] Current word on binaries

[Harald Maier]

"Eli Zaretskii" <eliz@elta.co.il> writes:

>> From: Harald Maier <harald@maierh.de>
>> Date: Sat, 14 Feb 2004 10:33:50 +0100
>> >
>> > I tried it too and I found too that something goes wrong. 'emacs -q'
>> > works fine, but when I tried to load my .emacs it displays the 'Emacs
>> > Abort Dialog' and complains that 'A fatal error has occured!'
>> 
>> I did some additional tests and it looks that the problem occurs only
>> if emacs-21.3 is compiled with a latest cygwin gcc. I did two test
>> with the emacs-21.3.tar.gz from March last year and the actual tarball
>> from ftp.gnu.org. On both sources the same happens, so it does not
>> look that something has changed since the compromise of the server.
>> Afterwards I compiled emacs with MSVC and the result is that all works
>> as expected. Currently I have no clue why the problem with gcc
>> happens.
>
> What version of GCC is the one that produces a bad binary?  What does
> "gcc --version" says?
>
> Can someone run Emacs under GDB and see where exactly does it abort?
>
> One possible idea to check is to use lower level of optimizations when
> building Emacs, like -O0 or -O1.  Can someone see if that produces a
> good binary?

It's gcc-3.3.1. I debugged the problem with insight and I got the
following backtrace in insight:

#1  0x01165be7 in w32_abort () at w32fns.c:14239
#2  0x01124db1 in Fbyte_code (bytestr=831842164, vector=1100249856, maxdepth=4) at bytecode.c:1710
#3  0x010234a7 in funcall_lambda (fun=1100290880, nargs=0, arg_vector=0x82ecf8) at eval.c:2851
#4  0x01022e7b in Ffuncall (nargs=1, args=0x82ecf4) at eval.c:2707
#5  0x01122e57 in Fbyte_code (bytestr=831842132, vector=1100249920, maxdepth=3) at bytecode.c:716
#6  0x01021cbc in Feval (form=1367136764) at eval.c:2019


The problem occured with the following command line:

$ emacs -q --no-site-file -l f:/home/maierh/local/elisp/html-helper-mode.el

,----
| ;;; html-helper-mode.el --- Major mode for composing html files.
| ;;; v 3.0.4jolly
`----

html-helper-mode is not the only example where it happens. As I
mentioned before with the current cvs emacs all works fine.

Harald

Re: [h-e-w] Current word on binaries

[Jason Rumney]

Harald Maier <harald@maierh.de> writes:

> It's gcc-3.3.1.

GCC 3.2 has the same problem. -O1 and -O0 do not help.

Re: Current word on binaries

[Harald Maier]

Jason Rumney <jasonr@gnu.org> writes:

> Harald Maier <harald@maierh.de> writes:
>
>> It's gcc-3.3.1.
>
> GCC 3.2 has the same problem. -O1 and -O0 do not help.

Ok, I remember it again. Last year there was a patch about _fmode and
O_BINARY for gcc -mno-cygwin. See herefor the the messages in
emacs-devel with:

,----
| Subject: [david.ponce@wanadoo.fr: Re: Issues with Windows gcc -mno-cygwin
|       (Mingw)]
`----

,----[ snippet from the emacs.c patch ]
| ! #if defined (MSDOS) || defined (WINDOWSNT)
|     /* We do all file input/output as binary files.  When we need to translate
|        newlines, we do that manually.  */
|     _fmode = O_BINARY;
| + #endif /* MSDOS || WINDOWSNT */
|   
| + #ifdef MSDOS
`----

I tried it and then it works fine. Is it not possible to add an file
to the /pub/gnu/emacs sources that describes the restriction or
mentinones the patch.

Harald

Re: [h-e-w] Current word on binaries

[Eli Zaretskii]

> From: Harald Maier <harald@maierh.de>
> Date: Sat, 14 Feb 2004 16:41:29 +0100
> 
> Ok, I remember it again. Last year there was a patch about _fmode and
> O_BINARY for gcc -mno-cygwin. See herefor the the messages in
> emacs-devel with:
> 
> ,----
> | Subject: [david.ponce@wanadoo.fr: Re: Issues with Windows gcc -mno-cygwin
> |       (Mingw)]
> `----

Sorry, I'm confused: what does this have to do with the problem at
hand?  Did you verify that the crash is related to this patch?

> ,----[ snippet from the emacs.c patch ]
> | ! #if defined (MSDOS) || defined (WINDOWSNT)
> |     /* We do all file input/output as binary files.  When we need to translate
> |        newlines, we do that manually.  */
> |     _fmode = O_BINARY;
> | + #endif /* MSDOS || WINDOWSNT */
> |   
> | + #ifdef MSDOS
> `----
> 
> I tried it and then it works fine. Is it not possible to add an file
> to the /pub/gnu/emacs sources that describes the restriction or
> mentinones the patch.

Why not simply patch the sources and be done with it?

Re: [h-e-w] Current word on binaries

[Harald Maier]

"Eli Zaretskii" <eliz@elta.co.il> writes:

>> From: Harald Maier <harald@maierh.de>
>> Date: Sat, 14 Feb 2004 16:41:29 +0100
>> 
>> Ok, I remember it again. Last year there was a patch about _fmode and
>> O_BINARY for gcc -mno-cygwin. See herefor the the messages in
>> emacs-devel with:
>> 
>> ,----
>> | Subject: [david.ponce@wanadoo.fr: Re: Issues with Windows gcc -mno-cygwin
>> |       (Mingw)]
>> `----
>
> Sorry, I'm confused: what does this have to do with the problem at
> hand?  Did you verify that the crash is related to this patch?

Yes, I added the patch and all worked fine. emacs-21.3.tar.gz was made
before that change of gcc. If you want to build emacs with newer gccs
you need that fix, otherwise you will get the errors as discussed.
IIRC that patch was added to the RC branch.

> Why not simply patch the sources and be done with it?

If this is possible, I don't have a problem with that. My only problem
is that the current emacs-21.3.tar.gz _sources_ in a actual cygwin
environment are useless. You will always get discussions about the
problem. Are there any plans to distribute the RC branch. That would
fix the problem too.

Harald 

Re: [h-e-w] Current word on binaries

[Eli Zaretskii]

> From: Harald Maier <harald@maierh.de>
> Date: Sat, 14 Feb 2004 18:24:08 +0100
> 
> > Why not simply patch the sources and be done with it?
> 
> If this is possible, I don't have a problem with that. My only problem
> is that the current emacs-21.3.tar.gz _sources_ in a actual cygwin
> environment are useless. You will always get discussions about the
> problem. Are there any plans to distribute the RC branch. That would
> fix the problem too.

I don't think there are plans to make another release from the branch,
but I didn't see any final word by Richard on this, so I guess it's
possible.

In any case, we could replace emacs-21.3.tar.gz with a tarball under
the same name where emacs.c is patched.  (We could call it
emacs-21.3a.tar.gz, if using the same name would confuse people.)

Re: [h-e-w] Current word on binaries

[Harald Maier]

"Eli Zaretskii" <eliz@elta.co.il> writes:

> In any case, we could replace emacs-21.3.tar.gz with a tarball under
> the same name where emacs.c is patched.  (We could call it
> emacs-21.3a.tar.gz, if using the same name would confuse people.)

That sounds really good to me.

Harald

Re: Current word on binaries

[Richard Stallman]

    Since it is deep within the byte code interpreter it is difficult to
    find what happened to get get the binding stack in that state.

You could disassemble the byte code and see if it is valid.
If it is valid, then debugging the byte code interpreter
might not be too hard.  One could determine what the stack
level should be at certain points in the function, and add
debugging code to test the actual stack level at those points.

One could also do this by adding a bytecode instruction to test
the binding stack level, and adding a flag to make the compiler
generate these instructions.  That would be a new debugging 
feature in the compiler.

Re: Current word on binaries

[Jason Rumney]

Richard Stallman <rms@gnu.org> writes:

>     Since it is deep within the byte code interpreter it is difficult to
>     find what happened to get get the binding stack in that state.
> 
> You could disassemble the byte code and see if it is valid.

I think we have pinpointed the cause. The .elc files were being
loaded as text files (on Windows this means dropping \r and
truncating on Ctrl-Z) due to a change in the defaults for GCC on
Windows sometime between 2.95 and 3.2. We already have a fix in CVS,
but it was not in 21.3.

We can either build the 21.3 release with an older version of GCC, or
patch the sources and release a 21.3a for Windows as suggested by Eli.

Re: [h-e-w] Current word on binaries

[Eli Zaretskii]

> From: Jason Rumney <jasonr@gnu.org>
> Date: 16 Feb 2004 20:38:06 +0000
> 
> I think we have pinpointed the cause. The .elc files were being
> loaded as text files (on Windows this means dropping \r and
> truncating on Ctrl-Z) due to a change in the defaults for GCC on
> Windows sometime between 2.95 and 3.2.

What change in the GCC defaults is that, and how can it affect the
text/binary issue in Emacs?

Re: [h-e-w] Current word on binaries

[Jason Rumney]

Eli Zaretskii <eliz@elta.co.il> writes:

> > From: Jason Rumney <jasonr@gnu.org>
> > Date: 16 Feb 2004 20:38:06 +0000
> > 
> > I think we have pinpointed the cause. The .elc files were being
> > loaded as text files (on Windows this means dropping \r and
> > truncating on Ctrl-Z) due to a change in the defaults for GCC on
> > Windows sometime between 2.95 and 3.2.
> 
> What change in the GCC defaults is that, and how can it affect the
> text/binary issue in Emacs?

The Emacs patch has been posted to this thread already. You commented
on it.

Re: [h-e-w] Current word on binaries

[Eli Zaretskii]

> From: Jason Rumney <jasonr@gnu.org>
> Date: 17 Feb 2004 08:56:15 +0000
> > 
> > What change in the GCC defaults is that, and how can it affect the
> > text/binary issue in Emacs?
> 
> The Emacs patch has been posted to this thread already. You commented
> on it.

I remember the patch, I just don't understand how this issue could be
uncovered by some change in the compiler.  To the best of my
understanding, the original code should have bitten us a long time
ago.

What am I missing?

Re: [h-e-w] Current word on binaries

[Jason Rumney]

"Eli Zaretskii" <eliz@elta.co.il> writes:

> I remember the patch, I just don't understand how this issue could be
> uncovered by some change in the compiler.  To the best of my
> understanding, the original code should have bitten us a long time
> ago.
> 
> What am I missing?

Linking with binmode.obj has been the way we have avoided being bitten
by MSVC in the past, but earlier versions of GCC defaulted to binary
mode and did not contain a binmode.obj (or .o) so that was made
conditional in the makefile. More recent versions of GCC now act more
like Windows compilers, defaulting to text mode and providing a
binmode.o to link with if you want binary mode as the default.

Re: [h-e-w] Current word on binaries

[Eli Zaretskii]

> From: Jason Rumney <jasonr@gnu.org>
> Date: 18 Feb 2004 00:13:32 +0000
> 
> 
> Linking with binmode.obj has been the way we have avoided being bitten
> by MSVC in the past, but earlier versions of GCC defaulted to binary
> mode and did not contain a binmode.obj (or .o) so that was made
> conditional in the makefile. More recent versions of GCC now act more
> like Windows compilers, defaulting to text mode and providing a
> binmode.o to link with if you want binary mode as the default.

So you are saying that the startup module supplied with GCC switched
from binary to text mode as the default?

Re: Current word on binaries

[Richard Stallman]

    We can either build the 21.3 release with an older version of GCC, or
    patch the sources and release a 21.3a for Windows as suggested by Eli.

We could make a 21.4 release from the release branch.
That might be a good idea anyway.

Re: [h-e-w] Current word on binaries

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Wed, 18 Feb 2004 03:38:33 -0500
> 
> We could make a 21.4 release from the release branch.
> That might be a good idea anyway.

I agree.  IIRC, 21.3 had a couple of annoying last-minute bugs.

Re: Current word on binaries

[Harald Maier]

Eli Zaretskii <eliz@elta.co.il> writes:

>> From: Richard Stallman <rms@gnu.org>
>> Date: Wed, 18 Feb 2004 03:38:33 -0500
>> 
>> We could make a 21.4 release from the release branch.
>> That might be a good idea anyway.
>
> I agree.  IIRC, 21.3 had a couple of annoying last-minute bugs.

Hello Eli,

I am not sure if I took the right version (EMACS_21_1_RC), but if this
is the current RC branch, then the patch for the discussed problem is
_not_ in the branch. Please, let me know the right RC tag if I'm wrong
and then I will double check again.

Harald

Re: [h-e-w] Current word on binaries

[Jason Rumney]

Harald Maier wrote:

>Eli Zaretskii <eliz@elta.co.il> writes:
>
>  
>
>>>From: Richard Stallman <rms@gnu.org>
>>>Date: Wed, 18 Feb 2004 03:38:33 -0500
>>>
>>>We could make a 21.4 release from the release branch.
>>>That might be a good idea anyway.
>>>      
>>>
>>I agree.  IIRC, 21.3 had a couple of annoying last-minute bugs.
>>    
>>
>
>Hello Eli,
>
>I am not sure if I took the right version (EMACS_21_1_RC), but if this
>is the current RC branch, then the patch for the discussed problem is
>_not_ in the branch. Please, let me know the right RC tag if I'm wrong
>and then I will double check again.
>  
>

The patch is not in there yet, because we had not decided to continue 
releasing from the
EMACS_21_1_RC branch until now. But that is the correct branch.

Re: Current word on binaries

[Jason Rumney]

[-- Attachment #1: Type: text/plain, Size: 679 bytes --]

Eli Zaretskii wrote:

>>From: Richard Stallman <rms@gnu.org>
>>Date: Wed, 18 Feb 2004 03:38:33 -0500
>>
>>We could make a 21.4 release from the release branch.
>>That might be a good idea anyway.
>>    
>>
>
>I agree.  IIRC, 21.3 had a couple of annoying last-minute bugs.
>  
>
Its a good idea if we can stick to a quick pretest cycle (a couple of 
weeks at the most). Otherwise the dragging out of the pretest will cause 
disillusioned users and distract the developers from getting CVS trunk 
into a releasable state. There are only a couple of minor bugfixes, so 
it should be possible to keep the pretest short if we purposely set out 
to do that and don't get distracted.


[-- Attachment #2: Type: text/html, Size: 1136 bytes --]

Re: [h-e-w] Current word on binaries

[Eli Zaretskii]

> From: Harald Maier <harald@maierh.de>
> Date: Wed, 18 Feb 2004 13:30:23 +0100
> 
> I am not sure if I took the right version (EMACS_21_1_RC), but if this
> is the current RC branch, then the patch for the discussed problem is
> _not_ in the branch. Please, let me know the right RC tag if I'm wrong
> and then I will double check again.

EMACS_21_1_RC is the right tag, as far as I remember.

Re: [h-e-w] Current word on binaries

[Eli Zaretskii]

> Date: Wed, 18 Feb 2004 13:43:24 +0000
> From: Jason Rumney <jasonr@gnu.org>
> >
> >I agree.  IIRC, 21.3 had a couple of annoying last-minute bugs.
> >
> Its a good idea if we can stick to a quick pretest cycle (a couple of
> weeks at the most).

Agreed.

I think this should be possible because, as you said, the release
branch didn't see commits for a long time.

The hardest thing would be to find a victim^H^H^H^H^H^Hvolunteer to
do package the tarballs and deltas and generally supervise the
release process.

Re: [h-e-w] Current word on binaries

[Jason Rumney]

Harald Maier <harald@maierh.de> writes:

> I am not sure if I took the right version (EMACS_21_1_RC), but if this
> is the current RC branch, then the patch for the discussed problem is
> _not_ in the branch.

The fix has been committed to EMACS_21_1_RC now, so a cvs update
should pick it up.

Emacs release procedure (Was: [h-e-w] Current word on binaries)

[Eli Zaretskii]

Here's a message sent in the past by Gerd Moellmann in which he
summarized the procedure he used for making a pretest/release
tarballs.  Note that the specific versions and tags mentioned may need
to be revised/modified for each specific release.

Francesco, if you have any comments based on your experience of
releasing v21.3, please do.

One issue I remember from my experience is that there are directories
present in the checked-out branch, such as lispref, which should not
be in the tarball.  They are there because they are present on the
trunk and because the RC branch tag exists on those directories as
well.  The solution is either to remove the directories in your local
sandbox, or (better) remove the branch tags from the files that are
not supposed to exist on the branch, and use "cvs update -P" to let
CVS prune empty directories when the tree is checked out.

I'm cc'ing emacs-devel so that this procedure is archived and could
be useful to future release managers.  I started a new thread for the
same reason.

------- Start of forwarded message -------
Subject: CVS tags
Reply-To: gerd@gnu.org
From: gerd.moellmann@t-online.de (Gerd Moellmann)
Date: 24 Mar 2002 20:42:06 +0100
X-Sender: 520015515780-0001@t-dialin.net
X-Status: A

I see in the change logs that 21.2 has been released.

Since there is no CVS tag for it, I wonder if I ever told that I did
tag the releases and pretests to facilitate diffing etc., or if I did
tell how I built the releases and pretests.  In case it's useful,
below is the exact procedure I followed.

1. cvs update

2. Run admin/build-configs to make sure Emacs builds in a number of
   frequently used configurations.  Fix bugs.

3. Bootstrap to make 100% sure all elc files are up-to-date, and to
   make sure that the later tagged version will bootstrap, should it
   be necessary to check it out.

4. Commit loaddefs.el, cus-load.el, finder-inf.el.

5. Run autoconf, commit configure.

5a. For a release, add released change log entries, and set the
   version number (M-x load-file RET admin/admin.el RET, then
   M-x add-release-logs RET, and M-x set-version RET).

6. make-dist --snapshot.  Check the contents of the new tar with 
   admin/diff-tar-files against an older tar file.

7. Make xdeltas

8. Untar the tar files made in 6, configure, build, install, saving
   the output of these phases with the script command.  Check the
   output, esp. check that Info files aren't built.  (Saving 
   the output of the last release diffing helps spotting problems.)

9. `cvs tag EMACS_PRETEST_21_0_105' in the toplevel Emacs dir.
   (I used `EMACS_21_1' for the release tag.)

10. Increment version numbers in versions.el, README, emacs.texi.
  (See 5a).

11. Upload & announce.
------- End of forwarded message -------

Re: [h-e-w] Current word on binaries (EMACS_21_1_RC on cygwin)

[Harald Maier]

Jason Rumney <jasonr@gnu.org> writes:

> Harald Maier <harald@maierh.de> writes:
>
>> I am not sure if I took the right version (EMACS_21_1_RC), but if this
>> is the current RC branch, then the patch for the discussed problem is
>> _not_ in the branch.
>
> The fix has been committed to EMACS_21_1_RC now, so a cvs update
> should pick it up.

Hallo Jason,

I took the changes and all works fine if emacs is compiled with no
optimizations (--no-opt). If I turn on optimizations then I get the
following re-producable errors. The most time I am using --no-opt, so
that's the reason why it worked for me before. Have you or others an
idea how to verify or debug the problem? I still have here also a MSVC
and a two year old MINGW runtime environment with that I can do some
debugging. Building emacs on that environments still works fine.

Harald

Loading help...
Loading international/mule-cmds...
Loading case-table...
Loading international/utf-8...
Loading international/utf-16...
Loading international/characters...
End of file during parsing: g:/cvs/emacs-cygwin/lisp/international/characters.elc
Signal 127
make.exe[1]: *** [oo-spd/i386/emacs.exe] Error 255
make.exe[1]: Leaving directory `g:/cvs/rc/emacs-cygwin/src'
d:\usr\mingw-make\bin\make.exe: *** [all-other-dirs-gmake] Error 2

Re: [h-e-w] Current word on binaries (EMACS_21_1_RC on cygwin)

[Harald Maier]

Harald Maier <harald@maierh.de> writes:

> Jason Rumney <jasonr@gnu.org> writes:
>
>> Harald Maier <harald@maierh.de> writes:
>>
>>> I am not sure if I took the right version (EMACS_21_1_RC), but if this
>>> is the current RC branch, then the patch for the discussed problem is
>>> _not_ in the branch.
>>
>> The fix has been committed to EMACS_21_1_RC now, so a cvs update
>> should pick it up.
>
> Hallo Jason,
>
> I took the changes and all works fine if emacs is compiled with no
> optimizations (--no-opt). If I turn on optimizations then I get the
> following re-producable errors. The most time I am using --no-opt, so
> that's the reason why it worked for me before. Have you or others an
> idea how to verify or debug the problem? I still have here also a MSVC
> and a two year old MINGW runtime environment with that I can do some
> debugging. Building emacs on that environments still works fine.
>
> Harald
>
> Loading help...
> Loading international/mule-cmds...
> Loading case-table...
> Loading international/utf-8...
> Loading international/utf-16...
> Loading international/characters...
> End of file during parsing: g:/cvs/emacs-cygwin/lisp/international/characters.elc
> Signal 127
> make.exe[1]: *** [oo-spd/i386/emacs.exe] Error 255
> make.exe[1]: Leaving directory `g:/cvs/rc/emacs-cygwin/src'
> d:\usr\mingw-make\bin\make.exe: *** [all-other-dirs-gmake] Error 2

FYI. Just figured out that same problem exists in CVS emacs.

Harald

Re: [h-e-w] Current word on binaries (EMACS_21_1_RC on cygwin)

[Richard Stallman]

    I took the changes and all works fine if emacs is compiled with no
    optimizations (--no-opt). If I turn on optimizations then I get the
    following re-producable errors.

In such a case, it is necessary to track down where in Emacs the code
executes wrong, much as if you were looking for any other kind of Emacs
bug.

Once the problem is localized, you may find code that is not
well-defined C.  Or you may find a line that is miscompiled.  If it is
the latter, we would want to send a GCC bug report.

    I still have here also a MSVC
    and a two year old MINGW runtime environment with that I can do some
    debugging.

If the problem does not happen with them, then they are irrelevant to
it.  The way to find a bug is to debug the case that fails.
Investigating cases that don't fail won't tell you about the failure.