DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0A6913857C4F
Message-ID: <bb6c5229-ce46-5fb3-c8c3-a19c0826d8d5@cornell.edu>
Date: Tue, 9 Nov 2021 21:53:35 -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>
In-Reply-To: <75197fd0-d5da-3236-a7df-b8ffc3f67da7@cornell.edu>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZWV1bDdoVW1JYjJTR21FSGg3QjF2emxRMUVrZ295cTJiN2JSMHFXOUo2ZFFk?=
 =?utf-8?B?clppRktZaDlPb3pJdkgwMzdoaTRJbU5vVVp3L0g2YWhad3FVQUtnZFcwbit6?=
 =?utf-8?B?V25NQWhMN21vN0FHZ1h3UjFWSnJIbkdabkR5YjJLZktvZ1pyMGRQTXdyUTBI?=
 =?utf-8?B?YXBrNkFOMHBRaUZtRk9iaFVVTHBJbWFMclBBdXBOcU9HTEhDaVdzZ09FUDJv?=
 =?utf-8?B?QUNPZTJUSmJsRFRZUDEvenlTOUx2dnFLT3pUUlFSemZUV3drTjRYdDh3OCt2?=
 =?utf-8?B?WmF2UUlQZjkwQ204czdKL3lKeThhOWlzMllXRkVCUWpKQWUxcnlnUGNoMEx1?=
 =?utf-8?B?QU5rZFlmQmE3d21YbFNGSzRhMFhRNVFSYzVYYSt6Mlg4aDdTemUrci9Pb1NF?=
 =?utf-8?B?eVRPS21UeExwdGFZVVd0cjduVlBsbTU1ZkxqT2RsYjY2QWZLSGNJaCtmRVla?=
 =?utf-8?B?ZzUrcVR3TWVOaldFMnk1QWwzLzZOWnV2bWF6Nnh6ZTBWVy94QUdhaWxpMkI0?=
 =?utf-8?B?cWcxNHFuZG1QNnR0cm90MElZd2xUS1ZFUThvVGlYUllUTS9ZVGV1MGxFc00z?=
 =?utf-8?B?R0UrRVlRNlV5VkJYZTNFZm5RbFZDaUdtempnWmlvT1VuVHhLblE5MW8rOW4x?=
 =?utf-8?B?aFJMYlRDTVJNbjdpS1lueDcyUE92SDc3ZU12NGR2aThJRHZpQWxaYjB0bTg3?=
 =?utf-8?B?Q2NwZVdLZ1I2dFJGekdDVXBnc0pnTXMvcEdMZWJETHZiMWJLd1E3TGM0UU1S?=
 =?utf-8?B?WStWMG9iNjE4bHA5Y1RTZjBobVZiaDU2bHhaL3Zhd0Z3VTZVV3Jpc0pqS2lJ?=
 =?utf-8?B?bXZvR3JWb2NIdkxmK3Q5YWtlWmFORG9HWnF4WmFMYkptM2t5eS93NUxSR3hI?=
 =?utf-8?B?S0dMTDNkRHFNN0dwcGprL3I5UlBJS0pqMVZmWXhBRThyNThxZlcxbzZGS3BX?=
 =?utf-8?B?V1ZHaElIc01ybE42MHlmOG93c0VBNGlGZ1ZCcDdjVzQ0cE1yUEdKTFp0UEd2?=
 =?utf-8?B?RmdIRXFYUlFDMGNpQXlHZFJSZ3NpNm03NHFJRVVlL1lINEJTbEJkZmV1YnhT?=
 =?utf-8?B?UW04cnhJcTF3MUxWejliR1ZhYmxrajBSQlRkQUZ2ME5mRjlZU3lqaXZNbEU4?=
 =?utf-8?B?bzhuNkVIQ25HbzZvYWN3ajYwVXVmT1hpLzd5Ri9oRVJFV3AvQjhGWHlmZ2Zo?=
 =?utf-8?B?L01RUFpyWkZxZFpacWNxS0huY2JYdWpjWTJ3ZTFoNU5oMkR3akpOcmN5MVF2?=
 =?utf-8?B?cm81VVhRQWlZV0NtR1BoMmZ3NGVkYnN2UnpVckEwRmg5VVd4aGNPWVFlV3VB?=
 =?utf-8?B?dmdPNGE1REdzbjIzSGd5ZmFHdXE1UUdZRnZtdmlseXA3elN3alEwZWNqTUJz?=
 =?utf-8?B?RnMyUEowMm04aE5RN1poaWluTU5oQ2Q4Q1E0ZlRZSVBpRk8rcEtRSlRsMEZJ?=
 =?utf-8?B?eTFnZENMbjV1Z2c5dXI0d2NPYktVLzB3SVltQkxZKzcxMm9KSkZwdHF2OVhV?=
 =?utf-8?B?dnFoblVuTGNpVWt2RVI2eGRraXk0OVlPTS8yTGtGYTJHRFg2Z2cwa09rZWht?=
 =?utf-8?B?UFNkb0dWN2dMb3pvc1l2R29FWHZqdlJQR2ozdjZqdXJLRXRwL2lrMzhoV1BU?=
 =?utf-8?B?UW1rbGN6UXI1d081eEtwS0ExUmZNZXFzSHFMYnhrZ2tWMVZnc2dDMy9KcmFv?=
 =?utf-8?B?UHB3TUFVcDhiMHV2bEwrNE5lTmV2cnJMeGN6anlaWjhtY3RWR0UvN3RvM0hT?=
 =?utf-8?B?S0FOb2FYVGpJN2FEWG5KcUtSdUF2SFVoWHRtUTNuTUdkbXVNZU8vTyttdUkz?=
 =?utf-8?B?RWRyNDUreXo5TjJ6WlZaY3ByWEsxclZvU0UxUm5wN2xRMXlCQW4raThvRXFB?=
 =?utf-8?B?T1ZlaGc0QmlhUCtWc2tWRExjZ2xkS214TVJOb2g1NDBtb3NES2Zta1lISlZl?=
 =?utf-8?B?NzFheStuTHdlNXkybk5xSUN5ME9BVi9xYTFrNS92VTl0ZUFFZTN4MUluQktL?=
 =?utf-8?B?SXVyTUdvMVQ3Vi8vUnpiM2Z3THFQM1gzMDg4N2lJa0VweDZhUlU1bXIxUERY?=
 =?utf-8?B?UFJtTzNZMEFkUTA0RmpsS25hZzdweEREeVNobzI3TzFXNzZiREhmVEt6M01o?=
 =?utf-8?B?SVA0dGtjT2lLdER2TEdJazkza1ExT1dGdUFzTzVnYkJLSm42M0xkRCtwZ2Fl?=
 =?utf-8?B?OGgwZFdnR0c0dDNFSS93Z0tmTmFwOFRJaTRKdmsxa0JtdnV0SWdLZTRDQkU5?=
 =?utf-8?Q?tXKdu+/YKRqEhHYi8hSSGqM8c6r5I+pBxzWSr/e0oo=3D?=
X-OriginatorOrg: cornell.edu
X-MS-Exchange-CrossTenant-Network-Message-Id: dada2a34-2bce-4aee-6ee6-08d9a3f54b20
X-MS-Exchange-CrossTenant-AuthSource: BN7PR04MB4388.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Nov 2021 02:53:37.3267 (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: tR6IguSlazA+6smzgT8En108pDo3lOlCraESrLotMss88zhajFZPzZFMR73WkO18Rpk630Et7NXwrFlMK7CsMg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR04MB5828
X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00, BODY_8BITS,
 DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, MSGID_FROM_MTA_HEADER,
 NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS,
 TXREP, URIBL_SBL_A 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-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 1AA2sB7j023017

On 11/9/2021 5:20 PM, Ken Brown via Cygwin wrote:
> On 11/9/2021 5:16 PM, Ken Brown via Cygwin wrote:
>> On 11/9/2021 9:11 AM, Ken Brown via Cygwin wrote:
>>> On 11/9/2021 5:55 AM, Henry S. Thompson wrote:
>>>> 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.
>>>
>>> I was aware that the bitbucket repo didn't exist, because I tried to get the 
>>> sources there.  But I didn't know about the fork.  Please point me to it, or 
>>> just make a tarball available to me somehow.
>>>
>>>> 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;
>>>>    }
>>> I'll have to reproduce the hang myself in order to test this (or maybe you 
>>> could test it), but I now have a new guess: If the read call above keeps 
>>> failing with EINTR, then we're in an infinite loop.  This could happen 
>>> because of the following code in fhandler_pipe::raw_read:
>>>
>>>    DWORD waitret = cygwait (read_mtx, timeout);
>>>    switch (waitret)
>>>      {
>>>      case WAIT_OBJECT_0:
>>>        break;
>>>      case WAIT_TIMEOUT:
>>>        set_errno (EAGAIN);
>>>        len = (size_t) -1;
>>>        return;
>>>      default:
>>>        set_errno (EINTR);
>>>        len = (size_t) -1;
>>>        return;
>>>      }
>>>
>>> Takashi, is EINTR really the appropriate errno in the default case?  Isn't 
>>> cygwait supposed to handle signals?
>>
>> I was able to build XEmacs and reproduce the problem.  My guess was wrong, 
>> though my question to Takashi still stands.  I think the infinite loop is 
>> actually caused by a bug in fhandler_pipe::raw_read that only affects 
>> non-blocking pipes (which is what we have in XEmacs).
>>
>> Consider the following code in fhandler_pipe::raw_read:
>>
>>        status = NtReadFile (get_handle (), evt, NULL, NULL, &io, ptr,
>>                 len1, NULL, NULL);
>>        if (evt && status == STATUS_PENDING)      <<<<<<<<<<<<<<<<<<<<<<<<<<<<
>>      {
>>        waitret = cygwait (evt, INFINITE, cw_cancel | cw_sig);
>> [...]
>>      }
>>
>> In the non-blocking case, evt == NULL, but we still might have status == 
>> STATUS_PENDING.  We then should wait on get_handle() to let NtReadFile finish. 
>> By not waiting, we end up using a garbage value from io.Information, leading 
>> to an infinite loop in drain_signal_event_pipe.

Nope, that doesn't seem to be the issue.  Even after fixing this, I still see an 
infinite loop.  Probably NtReadFile finishes quickly enough that io.Information 
is in fact valid by the time we test it.  Back to the drawing board.

> BTW, a quick glance at raw_write suggests that there might be a similar bug 
> there, but I'll have to look more closely.

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