Subject: Re: bug#79201: 30.1.90; set-process-thread can permanently break fd_callback_info slots

From: Spencer Baugh <[email-masked]>
Date: Wed, 13 Aug 2025 14:36:29 -0400

Eli Zaretskii <[email-masked]> writes:

>> From: Spencer Baugh <[email-masked]>
>> Cc: [email-masked],  [email-masked],  [email-masked],
>>    [email-masked]
>> Date: Wed, 13 Aug 2025 12:46:39 -0400
>> 
>> > Could the above scenario be the reason for what you see?
>> 
>> No, because the non-nil waiting_thread is seen in make-process, for a
>> process and file descriptor that is newly created.
>
> Then I think the descriptors was closed without clearing the
> .waiting_thread member.  So that goes back to what I suggested
> up-thread: delete_read_fd and delete_write_fd should clear these
> members.  They are called either after closing the descriptor or when
> we stop reading/writing to them, so their .waiting_thread member is no
> longer useful.

That doesn't explain why this is happening, though.  Descriptors are
always closed without clearing the .waiting_thread member.  Clearing
.waiting_thread is clear_waiting_thread_info's job.  Why isn't it
happening?

One theory: clear_waiting_thread_info only clears .waiting_thread up to
max_desc.  That's not it, though, because the bug still happens (albeit
slower) if I do:

@@ -670,7 +678,7 @@ clear_waiting_thread_info (void)
   int fd;
 
   eassert (max_desc < FD_SETSIZE);
-  for (fd = 0; fd <= max_desc; ++fd)
+  for (fd = 0; fd < FD_SETSIZE; ++fd)
     {
       if (fd_callback_info[fd].waiting_thread == current_thread)
 	fd_callback_info[fd].waiting_thread = NULL;