This is the mail archive of the cygwin-developers mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 12/10/2012 6:32 PM, Ryan Johnson wrote: > On 10/12/2012 8:41 PM, Daniel Colascione wrote: >> On 12/10/2012 5:36 PM, Ryan Johnson wrote: >>> I never reported it because I figured there was no way cygwin could make Windows >>> decide what files to cache or not cache... but it would definitely be nice to >>> see the problem go away. >> This behavior is definitely surprising. It's sort of an evil-genie way to >> provide cache coherency, I suppose. >> >>>> Now, if we run emacs.exe from cmd, not bash, that's exactly what happens: >>> <snip> >>>> I came up with a simple test case that reproduces in cmd the behavior I see >>>> when >>>> I run Emacs from bash. I've reproduced the program below. Here, I've compiled >>>> a.exe with -DSLOW: >>> I tried to test on my machine (w7 x64), but I can't get it to compile >>> (GetFileSizeEx not found at link time): >>> >>> i686-pc-mingw32-gcc emacs-slow.c -DSLOW -lkernel32 >> I just used i686-w64-mingw32-gcc. I didn't even need -lkernel32. > OK, that compiles, but I can't repro: > > $ time emacs-nox --batch -Q --eval '(kill-emacs)' > > real 0m0.057s > user 0m0.031s > sys 0m0.015s > > $ time emacs-nox --batch -Q --eval '(kill-emacs)' > > real 0m0.058s > user 0m0.031s > sys 0m0.015s > > $ time ./emacs-slow $(cygpath -wa $(which emacs-nox.exe)) > Success > > real 0m0.111s > user 0m0.000s > sys 0m0.060s > > $ time emacs-nox --batch -Q --eval '(kill-emacs)' > > real 0m0.058s > user 0m0.015s > sys 0m0.030s > > $ time ./emacs-fast $(cygpath -wa $(which emacs-nox.exe)) > Read 65536 bytes > Success > > real 0m0.148s > user 0m0.015s > sys 0m0.075s > > $ time emacs-nox --batch -Q --eval '(kill-emacs)' > > real 0m0.058s > user 0m0.030s > sys 0m0.015s > > Ideas? > Ryan I can't repro it with the stock emacs-nox or emacs-X11 either, even as administrator. But I can consistently repro it with any Emacs I build. More bizarrely, if I take an emacs binary I've build and hardlink it into /bin, I can repro the problem. If I _copy_ the binary instead of hardlinking it, I can't repro, even though the copy has the same hard link count and ACL as the hardlinked version. The key to generating a binary that repros the problem is to unexec emacs, then try to repro with that generated binary, not a copy of it. Maybe the process of modifying the binary during unexec borks the system's ASLR cache; I can't reproduce the problem with a simple testcase that copies and modifies the binary, but my test doesn't actually change the binary --- it just writes back to the destination binary exactly what we read from it.
Attachment:
signature.asc
Description: OpenPGP digital signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |