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 BCAC0388E81E for ; Tue, 16 Jun 2020 13:49:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org BCAC0388E81E 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 756FDA78EF; Tue, 16 Jun 2020 15:49:45 +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 cBe3taDLOBUe; Tue, 16 Jun 2020 15:49:44 +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 412F2A7CD4; Tue, 16 Jun 2020 15:49:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=CeBiTec.Uni-Bielefeld.DE; s=20200306; t=1592315384; bh=/KoOuRdOib0sATKTryxHfgwBsdSan3dNr5FNNzLrPHY=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=dOtsNFo6rL/bzwWL4I4YefM3Lh7etSJd+3etEEsSU8UhmZvUc+QX04vsAzacQogVN ZI/Pr2gEfGCa/jhkKH6C1R6GZp3AMK6ZKXmMebrOu+PqXD+syDCNBOA0TimHrRsKzT /1qar0D3M0dPTltSliPW8mR3d8qtbKHO1VkIBEvi5aLKHvwvCGB5WppHldRDRhGaCW OUiyRXC4cajrLGcQB/ewE+N8vIyUCj9/erxWIn8+yhQR8aZnIi9TUpd/MIN4EuFnWh 13r/wQh2PbY14Npcxe+M06xhfmZhV0d4lQNXArJ4pnpyL/SPrreuDwR854xANmYzde z+HhN2qdL2SzQ== From: Rainer Orth To: Joel Brobecker Cc: gdb-patches@sourceware.org Subject: Re: GDB 10.1 release: branching early July? References: <20200614015612.GA6242@adacore.com> <20200615230959.GJ7711@adacore.com> Date: Tue, 16 Jun 2020 15:49:43 +0200 In-Reply-To: <20200615230959.GJ7711@adacore.com> (Joel Brobecker's message of "Mon, 15 Jun 2020 16:09:59 -0700") 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.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, 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-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2020 13:49:48 -0000 Hi Joel, >> > * [RainerO] >> > [10 regression] run fails with ICE on Solaris >> > >> > Not sure if this is still an issue or not. Rainer did push some >> > patches to master back in May. To be confirmed. >> >> unfortunately, it is, and I didn't have much success debugging it. This >> makes gdb useless on Solaris and was introduced by the multi-target >> merge. I'm completely unfamiliar with that code and will need all the >> help I can get to get this resolved. > > Boooo... Understood. Maybe start a dedicated discussion on gdb-patches > with your current findings? Maybe Pedro can give you some pointers, > to help us debug and fix this thing? I guess that's the only option: at the glacial rate I'm currently making progress, a patch will be ready for GDB 11 at the earliest otherwise. > I see that you've already provided a bit of information in the PR > itself (https://sourceware.org/bugzilla/show_bug.cgi?id=25939), but > perhaps we could start with a summary of the situation, and what > you have found so far? For instance, IIUC, this affects debugging > of any program on Solaris. Are you still getting the same error? I've got to try that first, but assuming that the problem is in procfs.c (and maybe sol-thread.c), it's unlikely to have gone away in the meantime. > Your observation about a large number of threads being created is > interesting, and perhaps deserves to be dug into a little deeper, > considering that you think this wasn't happening with a version > prior to the multitarget patch series? I've now found where those are coming from: the thread name "gdb worker" visible in ps -L provided the necessary clue. They are due to worker threads now being enabled by default. On my desktop with 4 cores and hyperthreading, that's relatively harmless. However, when I run gdb on an 8-socket server with 160 cores total, the messages about thread creation when debugging gdb are killing you ;-) I traced this to maint.c (update_thread_pool_size) where the count defaults to std::thread::hardware_concurrency (). Maybe a bit over-eager... Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University