From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.CeBiTec.Uni-Bielefeld.DE (smtp.CeBiTec.Uni-Bielefeld.DE [129.70.160.84]) by sourceware.org (Postfix) with ESMTPS id C9D6E386F02B for ; Thu, 28 May 2020 16:01:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C9D6E386F02B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=CeBiTec.Uni-Bielefeld.DE Authentication-Results: sourceware.org; spf=none smtp.mailfrom=ro@cebitec.uni-bielefeld.de Received: from localhost (localhost [127.0.0.1]) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTP id B38FBB00FD; Thu, 28 May 2020 18:01:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at CeBiTec.Uni-Bielefeld.DE Received: from smtp.CeBiTec.Uni-Bielefeld.DE ([127.0.0.1]) by localhost (smtp.cebitec.uni-bielefeld.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id daTgVzivMZJ4; Thu, 28 May 2020 18:01:26 +0200 (CEST) Received: from manam.CeBiTec.Uni-Bielefeld.DE (p4fddbb33.dip0.t-ipconnect.de [79.221.187.51]) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTPSA id 14CB1B07A3; Thu, 28 May 2020 18:01:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=CeBiTec.Uni-Bielefeld.DE; s=20200306; t=1590681686; bh=WPZBZqfaXHH0BoacSr2rwF09Wo3s3dIbazGmP1AR6fg=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=Ew2dUUqJU++HzjGfWxNazbKiEZxkRpFkTkXua0o+cxPUDuczgA3kWIFBzmr/bXsEh A8iRU+o+zrkqkay5TIPdq62vgDP4dhlh8hJ+CTcK5eFDGKxelkg5nV9QOmXtoc6ZhJ lyOSPzADYhRu238Uc2jhhFjgoBSZlYnqn9T30u0gw+7HW9CjeJgTW5sz7ZRDetSqdW KXaEo+1L5mVYFT4mpcH/3ImO6xhwMYy8qpHD5OIqxNnaGqG4dhphnVLjtjsp/LAuZG 6hKGeQPWOKMGRoSxRoFzB4lliHE6/84qB2stE64jEZDYXSKQLeJe3lovF4WoUQ7mHf S3YFPWIrby6Lw== From: Rainer Orth To: Petr Sumbera via Gdb Subject: Re: Solaris - procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list References: <5ab0b8b1-6072-6717-1ae0-ba06339254b8@oracle.com> Date: Thu, 28 May 2020 18:01:24 +0200 In-Reply-To: <5ab0b8b1-6072-6717-1ae0-ba06339254b8@oracle.com> (Petr Sumbera via Gdb's message of "Thu, 28 May 2020 17:29:40 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-3791.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, KAM_SHORT, SPF_HELO_NONE, SPF_NONE, 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: Thu, 28 May 2020 16:01:29 -0000 Hi Petr, > I'm running into the issue below. Any suggestion how to this? > > # DISPLAY=:1 gdb /opt/firefox/bin/firefox > GNU gdb (GDB) 9.2 > Copyright (C) 2020 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > Type "show copying" and "show warranty" for details. > This GDB was configured as "sparc-sun-solaris2.11". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > . > Find the GDB manual and other documentation resources online at: > . > > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from /opt/firefox/bin/firefox... > (gdb) run -P > Starting program: /opt/firefox/bin/firefox -P > [Thread debugging using libthread_db enabled] > [New Thread 1 (LWP 1)] > [New LWP 2 ] [...] > [New LWP 26 ] > [LWP 20 exited] > [New LWP 20 ] > [LWP 21 exited] > [New LWP 21 ] > procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list. > procfs: couldn't find pid 32748 (kernel thread 21) in procinfo list. > (gdb) > > --- > > Is this Solaris GDB issue? Any suggestion where to look in GDB code? I'm seeing this relatively often when running the gdb testsuite (which makes it unsuitable to run make check on the Solaris gdb buildbots). I haven't yet gotten around to investigate closely, but the first places to check are procfs.c (the process layer, via /proc) and sol-thread.c (the thread layer, via libc_db). There's lots of old cruft in there from pre-Solaris 9 times with its NxM thread model, which both breaks a considerable number of test cases and makes the code harder to follow due to the added complexity/generality we don't need any longer. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University