Henry S. Thompson via Cygwin writes: > [XEmacs no longer works with Cygwin 3.3] > Ken Brown writes: > >> The main change was that we stopped using Win32 Overlapped I/O >> (https://docs.microsoft.com/en-us/windows/win32/sync/synchronization-and-overlapped-input-and-output) >> and switched to using the NT API. As a result, pipe I/O became much >> more efficient. It wouldn't surprise me if the efficiency alone is >> what exposed the bug. >> >> The good news is that the bug doesn't seem to occur in XEmacs 21.4 >> (on 32-bit Cygwin). So one way to approach this would be to bisect >> the XEmacs git repo to find the commit that introduced the bug. >> You'd probably have to do the work on 32-bit Cygwin since, if I >> remember correctly, XEmacs 21.4 didn't build on 64-bit Cygwin. > > Right, although I _suspect_ it will be in 64-bit-only code. Easy > enough to find out, once I resurrect a 32-bit install on a spare > machine that I can run 3.3 on (I use XEmacs all day every day from my > day job, so I need to stay with 3.2 until we fix this). Bisecting to isolate the change that causes the problem has taxed my debugging skills, and the fact that the answer appeared implausable at first slowed me down as well. I've included Aidan Kehoe in this thread as he's the relevant XEmacs expert, as author of the 'breaking' commit, namely o changeset: 5774:7a538e1a4676 | user: Aidan Kehoe | date: Thu Dec 19 18:13:11 2013 +0000 | files: src/ChangeLog src/file-coding.c src/text.c src/text.h | description: | Use skip_ascii() in no_conversion_convert() when encoding. | | src/ChangeLog addition: | | 2013-12-19 Aidan Kehoe | | * text.c: | * text.h: | * text.h (skip_ascii): | Move skip_ascii (), the very fast inline function from the | bytecount-to-charcount code, to text.h, to allow the coding | systems to use it too as needed. | * file-coding.c (no_conversion_convert): | Use skip_ascii() as appropriate here, halving the time taken to | write large files in my tests (again, relevant to VM buffers, but | not a panacea to our issues with them.) It seemed unlikely on the face of it that this change should break something in Cygwin's pipe handling nearly 8 years later. I eventually figured out that the problem lies not with the move of skip_ascii() itself, but with some #defines that moved with it. Because text.h is included (via lisp.h) by virtually every bit of the XEmacs source, _somewhere_ (and I haven't figured out where, see below for a guess) this interacts badly with _some_ aspect of the changes between Cygwin 3.2 and 3.3. Here are the suspects: #ifdef EFFICIENT_INT_128_BIT # define STRIDE_TYPE INT_128_BIT # define HIGH_BIT_MASK \ MAKE_128_BIT_UNSIGNED_CONSTANT (0x80808080808080808080808080808080) #elif defined (EFFICIENT_INT_64_BIT) # define STRIDE_TYPE INT_64_BIT # define HIGH_BIT_MASK MAKE_64_BIT_UNSIGNED_CONSTANT (0x8080808080808080) #else # define STRIDE_TYPE INT_32_BIT # define HIGH_BIT_MASK MAKE_32_BIT_UNSIGNED_CONSTANT (0x80808080) #endif #define STRIDE_ALIGN_BITS ((EMACS_UINT) (ALIGNOF (STRIDE_TYPE) - 1)) #define STRIDE_ALIGN_MASK (~ STRIDE_ALIGN_BITS) #define STRIDE_ALIGNED(ptr) ((((EMACS_UINT) ptr) & STRIDE_ALIGN_BITS) == 0) #define STRIDE sizeof (STRIDE_TYPE) Ken/Aidan, is it possible that the last line interacts badly with some (stale?) #ifdef code at lines 177 and 190 in sysdep.c [attached for Ken's benefit] in a way that only the new pipe code is sensitive to? Not urgent, as moving the above into a separate header file which is only used where needed fixes the problem. ht -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.