From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) by sourceware.org (Postfix) with ESMTP id C5561388C010 for ; Tue, 2 Jun 2020 17:14:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C5561388C010 Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-19-m5PuH0hsOxyoewprZdAOvQ-1; Tue, 02 Jun 2020 13:14:27 -0400 X-MC-Unique: m5PuH0hsOxyoewprZdAOvQ-1 Received: by mail-wm1-f72.google.com with SMTP id p24so1195078wmc.1 for ; Tue, 02 Jun 2020 10:14:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=AdDa921gW14qFUXIMKvW9uzyAzRcaFmEJ8bibQj90D8=; b=MkxDUyStcw6OjR2tuGXKhXuXWaRKTOuTpxiXjTdA75FqbnXI8GJDoaY968sZC8kN5/ OjRkdFZWqywWk0bQhIZJL/jAnxZXn9f1Rccx/z3XyhM9CAqJyoW0vVpDpqnQqx109icp 6oC0u00XdmD1/As/bBu8t5Wy5XyR/dk/pSoaGyQNsBlR8CY2dOeSLx2yqssvSFRK64Mm s9kk1cnh/D0nVCdHoRK9dNp5DY7j2EqjWquXod37WR183yIqwwB5SwqtFDp+lIuqNJx2 StUmLHxXe1i8tM3vZnkfXfXIIIjlix4y9OdB2f+Vqby6DhQgwz9lWMJUZIQurm6lgD0q lWKw== X-Gm-Message-State: AOAM53152EGvlrAR1r8TkeHf3felxtGhgO6c+YeguMa8sK5vNTHGleaZ g5ufN1nVyUcihGPS841Y4uJKlFD44k3P8KmxLA4PcF2/kWM38VH3b3/vVJsEK9/C1WzH2jCjc/X m9FkQiKQ7kZ0= X-Received: by 2002:adf:82c9:: with SMTP id 67mr29932285wrc.149.1591118066184; Tue, 02 Jun 2020 10:14:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyOJV+miuXAmO36VvamPNYnkpedSnPmybnVrcL7I22xG3wbsKRhM0+smOaPl1W3V7gpnJ6ZOw== X-Received: by 2002:adf:82c9:: with SMTP id 67mr29932269wrc.149.1591118065956; Tue, 02 Jun 2020 10:14:25 -0700 (PDT) Received: from ?IPv6:2001:8a0:f922:c400:56ee:75ff:fe8d:232b? ([2001:8a0:f922:c400:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id o15sm4920288wrv.48.2020.06.02.10.14.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Jun 2020 10:14:25 -0700 (PDT) Subject: Re: Solaris - procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list To: Petr Sumbera , gdb@sourceware.org References: <5ab0b8b1-6072-6717-1ae0-ba06339254b8@oracle.com> <0570473c-1181-2269-06a0-0f6d4fc6b178@redhat.com> <51ff2398-4a7d-eb07-be98-0ae92673e152@oracle.com> <6f4b62a6-3bcc-346e-ac69-a89e98f6dfbe@redhat.com> <405d3ffb-ea46-57cb-a023-7dece1983fb6@oracle.com> From: Pedro Alves Message-ID: <7fdd8e25-ccd3-00eb-ae30-b9f8c7604fd8@redhat.com> Date: Tue, 2 Jun 2020 18:14:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <405d3ffb-ea46-57cb-a023-7dece1983fb6@oracle.com> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 17:14:32 -0000 On 6/2/20 5:30 PM, Petr Sumbera wrote: > I have modified your change to gdb 9.2 and to correct occurrence (you have added it to second occurrence of 'exited'): > > --- ../../gdb-9.2/gdb/procfs.c.orig     2020-06-02 17:10:32.057735432 +0000 > +++ ../../gdb-9.2/gdb/procfs.c  2020-06-02 18:02:45.496117117 +0000 > @@ -2207,9 +2207,10 @@ >                     if (print_thread_events) >                       printf_unfiltered (_("[%s exited]\n"), >                                          target_pid_to_str (retval).c_str ()); > -                   delete_thread (find_thread_ptid (retval)); > -                   status->kind = TARGET_WAITKIND_SPURIOUS; > -                   return retval; > +                   thread_info *thr = find_thread_ptid (retval); > +                   if (thr) > +                     delete_thread (thr); > +                   goto wait_again; >                   } >                 else if (syscall_is_exit (pi, what)) >                   { > > But this time exited message repeats forever: > > [LWP    24         exited] > [LWP    24         exited] > [LWP    24         exited] Sounds like the LWP is stuck with the status, or the status is cached. We probably need to resume the process to move it out of the syscall, I guess. There's this bit in the file, at another spot we call goto wait_again: /* How to keep going without returning to wfi: */ target_continue_no_signal (ptid); goto wait_again; wfi == wait_for_inferior, the name of a function that used to be pretty core in infrun.c. Nowadays handle_inferior_event took the role. Try doing the same. Like: delete_thread (find_thread_ptid (this, retval)); target_continue_no_signal (ptid); goto wait_again; You may need to split the delete_thread/find_thread bits, or you may not. I'm not sure. The TARGET_WAITKIND_SPURIOUS handling in infrun.c also just calls resume(GDB_SIGNAL_0), so I _think_ this will work as well as before. I have no idea how this was supposed to handle the case of an LWP exiting while another one is single stepping. Looks like we lose the original single-stepping request. Maybe. Not sure. But doesn't look like we're making things any worse. Thanks, Pedro Alves