From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by sourceware.org (Postfix) with ESMTP id B191F388E80E for ; Tue, 16 Jun 2020 19:16:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B191F388E80E Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-250-eKMEYO3ROHy1KepbmU5_sw-1; Tue, 16 Jun 2020 15:16:41 -0400 X-MC-Unique: eKMEYO3ROHy1KepbmU5_sw-1 Received: by mail-wm1-f70.google.com with SMTP id q7so1301181wmj.9 for ; Tue, 16 Jun 2020 12:16:41 -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=qsXNJZR0n9yVl3+K7+RDLr0mxNEyHlif+Gdx49o17cw=; b=S/3MrOLjbXm5BEMjWp3rgz68oUEa0mo9FvrVF4I3S24N6eT811tyuqtapS+mX5LkDI /oHPXDEiWF2NVDW0p4UuGRywv5uO0Pf747XYjx+VyuYilq7ADqQSa9AbtzvUTXt/7XLb iy+GJHw3gQmiM0P2WlV8dvVCgHFGU1Bmht96WNgXqn3p7sVMcrWDFJgrPaB4u4LbO+oO 3VGbx/dlY51J/6DkoA24EG285aaGL/XF7aQk9Oqz4U2M60oSUo5iDcC6redqef6jF6ch wsTs7reZEnWI+Ir4GMTCVBN9ESTLCU8/SWPa/RnPPMApSG+baRpncCpUEnKYYOZvp3U1 K3MA== X-Gm-Message-State: AOAM531X22lVX3DHRhl6ttixyyOJgz0Oyx6CwIluwHPHhil6njTJJoP5 qyj5yiPJ8LynORazJ3hs4NJaafJmwvyPywGyQO2Y443BtQFvGYW0E6ebFeDW0EfI6irkIhrG/pJ H+G5a0IBx2Eku95ddtSo+2Q== X-Received: by 2002:a5d:6905:: with SMTP id t5mr4470342wru.113.1592334999991; Tue, 16 Jun 2020 12:16:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwGjq1MbkGBiqZTAqSGOuhiUB4+zLVLEvZc2gNXdOPrpUSoFyxVqN/7YCSJLcQFiLeOwBF06w== X-Received: by 2002:a5d:6905:: with SMTP id t5mr4470324wru.113.1592334999587; Tue, 16 Jun 2020 12:16:39 -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 l1sm34463577wrb.31.2020.06.16.12.16.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 16 Jun 2020 12:16:39 -0700 (PDT) Subject: Re: Unbreaking gdb on Solaris post-multitarget [PR 25939] To: Rainer Orth , gdb-patches@sourceware.org References: From: Pedro Alves Message-ID: <7fb790ae-61a9-a6a3-3b87-74fcac400664@redhat.com> Date: Tue, 16 Jun 2020 20:16:38 +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: Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00, 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-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 19:16:44 -0000 On 6/16/20 3:21 PM, Rainer Orth wrote: > Some time ago, when testing gdb master on Solaris again after several > months, I discovered that gdb couldn't execute even a trivial program > anymore. This had gone unnoticed by the Solaris buildbots since the > code continued to compile just fine. Those bots are build-only since > many tests (especially thread tests) are either flaky or time out. > > A reghunt identified the multi-target merge as the culprit. I'm sorry about that. > I've managed to get a bit further with the following patch which is > intended to push the procfs target first: That patch looks good to me. > > > However, while I now get over the initial assertion failure, I run > instead into > > procfs: couldn't find pid 0 in procinfo list. > procfs: init_inferior, open_proc_files line 2878, /proc/6031: No such file or directory. > > When I break in procfs.c (procfs_init_inferior), I can see that > create_procinfo succeeds. However, looking at the process tree at this > point, I see that the debuggee is still marked as defunct > > 18377 /vol/gcc/bin/gdb -i=mi /vol/gnu/obj/gdb/gdb/reghunt/no-r > 18379 /vol/gnu/obj/gdb/gdb/reghunt/no-resync/122457/gdb/gdb > 18382 > > so open_procinfo_files fails because /proc/ only contains psinfo > and usage, but no ctl file yet. > > I tried to do the same with a version of gdb from immediately before the > multi-target merge: while that can run a test program interactively just > fine, It's not clear to me whether you're saying that a version from before the multi-target changes can run a test program fine due to not needing the push_target fix, or whether the multi-target patchset itself caused this second issue you're observing even when debugging a simple hello program. running that gdb under gdb itself most often leads to the same > error. This very much seems like a race condition to me, but at the > moment I'm pretty much at a loss how to investigate this further. Could this be a race somehow more exposed now due to GDB now spawning worker threads? What happens if you debug a GDB that doesn't spawn worker threads? Like: ./gdb -D ./data-directory --args ./gdb -ex "maint set worker-threads 0" Does that problem trigger as often that way? Or, what happens if you use master GDB with your push_target fix to debug an older GDB? Thanks, Pedro Alves