DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1B65A3857805
Message-ID: <4b937b32-e348-19d2-2406-c55fa12e20a3@cornell.edu>
Date: Wed, 10 Nov 2021 09:47:31 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.3.0
Subject: Re: Another pipe-related problem?
Content-Language: en-US
To: cygwin AT cygwin DOT com
References: <f5br1bqaj11 DOT fsf AT ecclerig DOT inf DOT ed DOT ac DOT uk>
 <05c4180e-396b-4af3-ac0c-2ab8125df17e AT cornell DOT edu>
 <f5bk0hh8uox DOT fsf AT ecclerig DOT inf DOT ed DOT ac DOT uk>
 <eb8d7d4f-d1ed-6f30-2ac3-1b24166243d9 AT cornell DOT edu>
 <0971ace1-5ee8-bdcc-5fd9-4551b294ebf8 AT cornell DOT edu>
 <75197fd0-d5da-3236-a7df-b8ffc3f67da7 AT cornell DOT edu>
 <bb6c5229-ce46-5fb3-c8c3-a19c0826d8d5 AT cornell DOT edu>
In-Reply-To: <bb6c5229-ce46-5fb3-c8c3-a19c0826d8d5@cornell.edu>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?S2crOENXaFJwUW4wTWlzTUFzL21OTnlWaVpQMHdDdStMVjRZVC81a1ZUR2Fv?=
 =?utf-8?B?d1VWaFptVmpNTktPTEFaQ3ZLSVd2VFN4ZnVoL1J1T2NlYitXeHFjcVdXMkVo?=
 =?utf-8?B?dzRkSkVyK2hiQnhqeUxXejd3ZVh4ajQ4dmMyNUJ2TkRNVVRCMjVURkFkbXRY?=
 =?utf-8?B?dkRLUXhaUnY3MkpqUXFqZ0U0clhTeEtBU3NLRUI5Tnc3VjA1L2owejNKbFBJ?=
 =?utf-8?B?ZlRzSFZDWGtjTTJnalF4ZFVqSmh1WHZ3ZWFJcjRkaGhMTzB6a21vQ3l4Vm41?=
 =?utf-8?B?QUZCdmp1NVUzVDROWEJzTDlzNEk4MjdST1RSZ1NjdlBxNEh5QjdpamVKZmNi?=
 =?utf-8?B?YzZtREJOMmRvRWlUMzhod0tLNWZTOTdDa3NjbnJWWWUyTjY2dTlSbzhRY3g5?=
 =?utf-8?B?NHQ2aS81TWxzUUV3dlF1VVVPekhrSmdGMkhKd0lCdWswdURwRjUyaldiMS8r?=
 =?utf-8?B?Qm9RRkRHWUlWd3didVRmOGZ3eWsvRDRnM3N1SXQ0bkQxMStGZTYrbysxT1ow?=
 =?utf-8?B?cmxoU281TXJmZ2w5b3hadjlmcGNCTURnb3NieFdNeURXUHRmV3BnQkFkOVJE?=
 =?utf-8?B?aXdkK2ZQMDZ1NUVwSFBFV3NuTUhmaHZTd2R6eSs2c1p6Y2dhR05lRzhEdG5T?=
 =?utf-8?B?eVhKQzBSRWQwbkNON2R6ZFhqblJnTDRjSlRIbkdrVFR6SFBwK3dpcjVubEpy?=
 =?utf-8?B?YU1FbGo3bytXakhETk93QWJnR0UxUm5KeEpUUlZqVzZoVGNlMzdQamxhMjRu?=
 =?utf-8?B?VXdZVXUza1RNRWE1ZVdSZWx1aGRzMHlYdTdRRUtCa2ZKRXQ4N1Npb05mYWN2?=
 =?utf-8?B?dVZlMGhsSWx5YVZiZlRyUUFvd2hXV0dpbkJ2ck1yY1JleFo0VmdyNWJJb0VD?=
 =?utf-8?B?V09Qd3RVMlVVb2ZNV2RCYUJHWUU5NUpHNjBzQkpENlJtcEsxcGZpeXhKWW9z?=
 =?utf-8?B?NXNHZ0NhcEhYSHRiMWpzTWpyenp1MjhEa04reGlvbFRDNWlVUXpBdjlrbDFE?=
 =?utf-8?B?RkR4bHp1N3ZUc1EyTmk5WTNQbXVPUThJQmJqR3lQbXZzdnhhQ3oxdURRMGMv?=
 =?utf-8?B?VEszMVFyTEpWWkdiR2RYcHhFd1hsU2puV3B1UnRzTDEraFhGVStxUXhtZGww?=
 =?utf-8?B?SXNlaERjOGtvbGExRzhnQy9TSkdQbzgwajJRS0NDcDZHYm9ybWdvSllsWTF2?=
 =?utf-8?B?TG9GM1BlRllJN3NjQlVYekZobVhzbzNxeTFNTGt2bTQ4dk5JMFNsSnhrTlBw?=
 =?utf-8?B?YWVweHpuTGpLSWtTb3Z3emtJT1BNS2FHVUhnQlI3QVU2aUxCVkczaEZ6Rjha?=
 =?utf-8?B?SXFTSXl0dmF5TlBoNjBRYmdKME5ldERONnIvcTh2YnQwTE1ybnBaaVZlRU5o?=
 =?utf-8?B?UWZEbzQzMzFuQmlZaHlid1ZkOXpaVWtNVW1PblQrMmkzaEZYTGwvTmkwNXJR?=
 =?utf-8?B?ZzJkSDRZTzJqQXpBVDVjOThZZ1pRZ20xQXNsMkZpQXVITzdTTDdJY1BVYXJq?=
 =?utf-8?B?VU5idnhMN0FSaEUyQUc4ZCs5MFRlSDFybzJKUG9WZGhBWHROdDhmV3Q5VWdJ?=
 =?utf-8?B?MmhZcUFWYktNWUo3MlBSNnVLcnVEOGdtWlN4OFFZK0tuVTZTTGpPdzJvRW9K?=
 =?utf-8?B?VXltQ0QxUmxWY013MU5DYmJ4ZklzWnludXh0azdnMmtrMENvNVAyY0ZDTkd5?=
 =?utf-8?B?eFA5MURudHpxbUxXMkphQkdUZksycEh1SFVSVlRFbFFLVFZtYmhZdFJXU21B?=
 =?utf-8?B?UUhuK0lMZVUwcEVtWkx4VERMM1VBbVdkSDNKT3h4RFdpU2k3MHRCZXBvVGxD?=
 =?utf-8?B?UzlPcnFzdXRVQkRvWGV2aUNLc2NNRVFoNC84d0dwaDRsSkRUcVo2dDhCMUVQ?=
 =?utf-8?B?aEpDWmNhTGFPczRwbGswclJhSHN3eTcrUFJzWnFTYzBZQ0VhQkhFeEpiS1ln?=
 =?utf-8?B?enh4cjVvUUhIQzVJSkhGeU9UUHB4WERTaFlUMXFxK2pkVm9ya05HMkI0REp5?=
 =?utf-8?B?U2VnbkR5bHhPcXFNdVpvd0tzVnh1dFgzb05KRFlwQksvTzhEWkdVek1pR1cy?=
 =?utf-8?B?TFl3UzM0SHd2SUxpZFJUSVVlREhVL1RYYTd0YklxUzEzWDhkYXRpUVRDTHla?=
 =?utf-8?B?T2dERE5walBBQm9ZOTB3M3poWUpFNmNySVBIRVFsVDFlNjZ0aEFaWTIzQnBo?=
 =?utf-8?B?M3Q1MjZKeDlxWHdaVUtiSm9UNE0xZ21Bb09odjd1RDVWVWNSYjlOTXk1UHd6?=
 =?utf-8?Q?OdYOHm5qCxyqX50U+b0z3V3r6iKCHnuGi8KkB/fPiM=3D?=
X-OriginatorOrg: cornell.edu
X-MS-Exchange-CrossTenant-Network-Message-Id: 9870d4d5-67ab-43a0-f508-08d9a4590749
X-MS-Exchange-CrossTenant-AuthSource: BN7PR04MB4388.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Nov 2021 14:47:33.2696 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 5d7e4366-1b9b-45cf-8e79-b14b27df46e1
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: UDUB9kUerispkGRG352ou4ii1GJE3aRQ9vmyCj524M7rDUw84UtZ17s6YGZl+jQ651TuL3HVCcIKfh9eIWvNTw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR04MB3842
X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, JMQ_SPF_NEUTRAL,
 MSGID_FROM_MTA_HEADER, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,
 SPF_HELO_PASS, SPF_PASS, TXREP,
 WEIRD_PORT autolearn=ham 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 AT cygwin DOT com
X-Mailman-Version: 2.1.29
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From: Ken Brown via Cygwin <cygwin AT cygwin DOT com>
Reply-To: Ken Brown <kbrown AT cornell DOT edu>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>

On 11/9/2021 9:53 PM, Ken Brown via Cygwin wrote:
> Back to the drawing board.

It finally occurred to me to stop looking for a bug in fhandler_pipe::raw_read 
and instead see if something is in fact repeatedly writing to the pipe, so that 
drain_signal_event_pipe never finishes.  Putting a breakpoint at 
fhandler_pipe::raw_write, I found that this is in fact the case.  While the main 
thread is repeatedly reading from the pipe, a second thread is repeatedly 
writing to it.  Here's the backtrace of that thread:

#0  fhandler_pipe_fifo::raw_write (this=0x18039f370, ptr=0x2c4ca3b, len=1)
     at ../../../../temp/winsup/cygwin/fhandler_pipe.cc:430
#1  0x000000018006f39a in fhandler_base::write (this=0x18039f370,
     ptr=0x2c4ca3b, len=1) at ../../../../temp/winsup/cygwin/fhandler.cc:907
#2  0x0000000180158fd1 in write (fd=4, ptr=0x2c4ca3b, len=1)
     at ../../../../temp/winsup/cygwin/syscalls.cc:1360
#3  0x00000001801b9b5b in _sigfe () at sigfe.s:35
#4  0x00000001006ae471 in retry_write_1 (fildes=4, buf=0x2c4ca3b, nbyte=1,
     allow_quit=0) at sysdep.c:2364
#5  0x00000001006ae581 in retry_write (fildes=4, buf=0x2c4ca3b, nbyte=1)
     at sysdep.c:2386
#6  0x00000001004b3ba5 in signal_fake_event () at event-unixoid.c:149
#7  0x0000000100691060 in alarm_signal (signo=14) at signal.c:559
#8  0x00000001006ec6e4 in mswindows_raise (nsig=14) at win32.c:694
#9  0x00000001006ec72d in setitimer_helper_proc (unused_uID=96, unused_uMsg=0,
     dwUser=14, unused_dw1=0, unused_dw2=0) at win32.c:742
#10 0x00007ffb363c2811 in WINMM!PlaySoundW () from /c/WINDOWS/SYSTEM32/WINMM.dll
#11 0x000000018004771c in _cygtls::call2 (this=0x2c4ce00,
     func=0x7ffb363c26c0 <WINMM!PlaySoundW+3440>, arg=0x0, buf=0x2c4cce0)
     at ../../../../temp/winsup/cygwin/cygtls.cc:40
#12 0x00000001800476c1 in _cygtls::call (
     func=0x7ffb363c26c0 <WINMM!PlaySoundW+3440>, arg=0x0)
     at ../../../../temp/winsup/cygwin/cygtls.cc:27
#13 0x00000001800e4f15 in threadfunc_fe (arg=0x0)
     at ../../../../temp/winsup/cygwin/init.cc:28
#14 0x00007ffb43da7034 in KERNEL32!BaseThreadInitThunk ()
    from /c/WINDOWS/System32/KERNEL32.DLL
#15 0x00007ffb448c2651 in ntdll!RtlUserThreadStart ()
    from /c/WINDOWS/SYSTEM32/ntdll.dll
#16 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

This looks to me like an XEmacs bug that happens to be triggered by the new pipe 
code, although maybe there's also a Cygwin bug that I'm not seeing.  The comment 
at the beginning of signal_fake_event might be relevant:

void
signal_fake_event (void)
{
   Rawbyte rbyte = 0;
   /* We do the write always.  Formerly I tried to "optimize" this
      by setting a flag indicating whether we're blocking and only
      doing the write in that case, but there is a race condition
      if the signal occurs after we've checked for the signal
      occurrence (which could occur in many places throughout
      an iteration of the command loop, e.g. in status_notify()),
      but before we set the blocking flag.

      This should be OK as long as write() is reentrant, which I'm fairly
      sure it is since it's a system call. */

   if (signal_event_pipe_initialized)
     /* In case a signal comes through while we're dumping */
     {
       int old_errno = errno;
       retry_write (signal_event_pipe[1], &rbyte, 1);
       errno = old_errno;
     }
}

Ken

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple