From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from loire.is.ed.ac.uk (loire.is.ed.ac.uk [129.215.16.10]) by sourceware.org (Postfix) with ESMTPS id CA8FE3858428 for ; Tue, 9 Nov 2021 10:55:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CA8FE3858428 Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.202.41]) by loire.is.ed.ac.uk (8.14.7/8.14.7) with ESMTP id 1A9AtRIW031916 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 9 Nov 2021 10:55:27 GMT Received: from ecclerig.inf.ed.ac.uk (ecclerig.inf.ed.ac.uk [129.215.24.151]) by crunchie.inf.ed.ac.uk (8.14.7/8.14.7) with ESMTP id 1A9AtPrC024775; Tue, 9 Nov 2021 10:55:25 GMT Received: by ecclerig.inf.ed.ac.uk (Postfix, from userid 27024) id 04FED120271; Tue, 9 Nov 2021 10:55:27 +0000 (GMT) To: Ken Brown Cc: cygwin@cygwin.com Subject: Re: Another pipe-related problem? References: <05c4180e-396b-4af3-ac0c-2ab8125df17e@cornell.edu> From: "Henry S. Thompson" Date: Tue, 09 Nov 2021 10:55:26 +0000 In-Reply-To: <05c4180e-396b-4af3-ac0c-2ab8125df17e@cornell.edu> (Ken Brown via Cygwin's message of "Mon\, 8 Nov 2021 09\:35\:53 -0500") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b34 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at loire.is.ed.ac.uk X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP, URIBL_SBL_A autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2021 10:55:35 -0000 Ken Brown via Cygwin writes: > On 11/8/2021 8:12 AM, Henry S. Thompson via Cygwin wrote: >> Running on Windows-10 21H1 >> >> With Cygwin 3.3.0 and 3.3.1 I get a hang every time I try to launch XEmacs: >> >> .. >> #6 0x000000018013ffcc in read (fd=3, ptr=0xffff0bc0, len=) >> at /usr/src/debug/cygwin-3.3.1-1/winsup/cygwin/dtable.h:64 >> #7 0x000000018018e88b in _sigfe () at sigfe.s:35 >> #8 0x000000010066a11d in retry_read_1 (fildes=3, buf=0xffff0bc0, nbyte=128, >> allow_quit=0) at sysdep.c:2425 >> #9 0x000000010066a171 in retry_read (fildes=3, buf=0xffff0bc0, nbyte=128) >> at sysdep.c:2437 >> #10 0x0000000100494d86 in drain_signal_event_pipe () at event-unixoid.c:159 >> #11 0x000000010056d1dc in mswindows_need_event (badly_p=1) at event-msw.c:1432 >> >> This is an old executable, has worked since 2015 (!), but recompiling >> didn't help. Reverting to 3.2 lets it run again. > > This backtrace doesn't match the source of Cygwin's XEmacs package > (which exists on 32-bit Cygwin only), so I assume you built this > yourself, using a different version of XEmacs. Cygwin's XEmacs > doesn't hang for me. Thanks for looking in to this! And you're right, it's a local build. I was responsible for producing the 64-bit XEmacs back in 2015, but could never get a Visual Studio build to work at that time, so it was never released. > Please provide build instructions for the version you compiled. As you may know, the XEmacs situation is complicated. The old source repo (bitbucket.org/xemacs) no longer exists. There's a fork that's still being maintained, but it's not widely publicised. That's the one I'm working with -- are you aware of this. > Your backtrace shows that fhandler_pipe::raw_read is blocked waiting > for a mutex, but I can't tell why without seeing the XEmacs source. > My guess, just from looking at the function names, is that XEmacs is > mixing POSIX reads with Win32 reads, messing up the mutex handling. If you have access to the public sources vintage mid-2015 or later, the following might work: ./configure '--with-pdump=yes' '--with-modules=no' '--with-mule=yes' '--with-ncurses=yes' '--with-msw=yes' '--with-xpm' '--with-tls=no' '--without-x' make src/xemacs --vanilla Otherwise let me know and I'll point you at the current repo. Here are the immediate contexts from the sources for the xemacs sources in the above backtrace, might be enough to check your hypothesis: sysdep.c: retry_read_1 (int fildes, void *buf, size_t nbyte, int allow_quit) { ssize_t rtnval; while ((rtnval = read (fildes, buf, nbyte)) == -1 && (errno == EINTR)) { if (allow_quit) QUIT; } return rtnval; } ssize_t retry_read (int fildes, void *buf, size_t nbyte) { return retry_read_1 (fildes, buf, nbyte, 0); } event-unixoid.c: drain_signal_event_pipe (void) { Rawbyte chars[128]; /* The input end of the pipe has been set to non-blocking. */ while (retry_read (signal_event_pipe[0], chars, sizeof (chars)) > 0) ; } event-msw.c: /* * This drains the event queue and fills up two internal queues until * an event of a type specified by USER_P is retrieved. * * * Used by emacs_mswindows_event_pending_p and emacs_mswindows_next_event */ static void mswindows_need_event (int badly_p) { while (NILP (dispatch_event_queue) && NILP (mswindows_s_dispatch_event_queue)) { #ifdef CYGWIN int i; int active; SELECT_TYPE temp_mask = input_wait_mask; EMACS_TIME sometime; EMACS_SELECT_TIME select_time_to_block, *pointer_to_this; if (badly_p) pointer_to_this = 0; else { EMACS_SET_SECS_USECS (sometime, 0, 0); EMACS_TIME_TO_SELECT_TIME (sometime, select_time_to_block); pointer_to_this = &select_time_to_block; if (in_modal_loop) /* In modal loop with badly_p false, don't care about Windows events. */ FD_CLR (windows_fd, &temp_mask); } mswindows_is_blocking = 1; active = select (MAXDESC, &temp_mask, 0, 0, pointer_to_this); mswindows_is_blocking = 0; if (active == 0) { assert (!badly_p); return; /* timeout */ } else if (active > 0) { if (FD_ISSET (windows_fd, &temp_mask)) mswindows_drain_windows_queue (badly_p); else { #ifdef HAVE_TTY /* Look for a TTY event */ for (i = 0; i < MAXDESC; i++) { /* To avoid race conditions (among other things, an infinite loop when called from Fdiscard_input()), we must return user events ahead of process events. */ if (FD_ISSET (i, &temp_mask) && FD_ISSET (i, &tty_only_mask)) { struct console *c = find_tty_or_stream_console_from_fd (i); Lisp_Object emacs_event = Fmake_event (Qnil, Qnil); Lisp_Event *event = XEVENT (emacs_event); assert (c); if (read_event_from_tty_or_stream_desc (event, c)) { mswindows_enqueue_dispatch_event (emacs_event); return; } } } #endif /* Look for a process event */ for (i = 0; i < MAXDESC; i++) { if (FD_ISSET (i, &temp_mask)) { if (FD_ISSET (i, &process_only_mask)) { Lisp_Process *p = get_process_from_usid (FD_TO_USID (i)); mswindows_enqueue_process_event (p); } else { /* We might get here when a fake event came through a signal. Return a dummy event, so that a cycle of the command loop will occur. */ drain_signal_event_pipe (); mswindows_enqueue_magic_event (NULL, XM_BUMPQUEUE); } } } } } else if (active == -1) { if (errno != EINTR) { /* something bad happened */ assert (0); } } else { assert (0); } #else /* not CYGWIN */ ... Thanks again, ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.