From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) by sourceware.org (Postfix) with ESMTPS id 857B03898C6B for ; Fri, 29 Apr 2022 12:50:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 857B03898C6B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-f49.google.com with SMTP id p189so4575443wmp.3 for ; Fri, 29 Apr 2022 05:50:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=44pjDodyAYemAH6j0qeCoaPF7PRGBEEJjsKVq7FLW9g=; b=YHJJSGv/iIjdSSXUHPD4Iy7Hq9aMCAMlyWpfX9t2iZuv9NhxylXxfANn11GMpkV3a+ 1PdxSa2cVQbFSwcCQ5NTVVNMo7OQPjys9HLCvEnk92gorMxOqmsVjnVCNjP/rFOP5Pt6 2qQNeu5QJ5s9+gungElg+43P0th6li7VbbWKzrGYlZwhWDlSVp+M4X+E0M2iAwK27B9o uIhsvhRIFfWUanNWYS3LXy77wHjRnHb7jJWEtSnpfHd1O1VvtNnvNv7UXDpLyZhD7QCs ixFKS5vEdk0ylE/RKqQiL/t11feg2+Nz3pPAd+kpaAtYWrsKATSUD6VNwbuIGEMZRLVn 4w9g== X-Gm-Message-State: AOAM5302AZhupDmZryNyh7YyH6A3dRUKa/kO+CMr159ACgtydsAJ6uzm /hceSFIIrzHPvJ96/s1wHgKLB/K+ZU0= X-Google-Smtp-Source: ABdhPJw9xxGNy2pYKJ3XXcZq+H+VbX2K+w86IP2lvQzpE1YLBLL8irLU66rmv6KNNGH0/djOp0u9CA== X-Received: by 2002:a7b:c5cd:0:b0:38c:8b1b:d220 with SMTP id n13-20020a7bc5cd000000b0038c8b1bd220mr3043094wmk.118.1651236646391; Fri, 29 Apr 2022 05:50:46 -0700 (PDT) Received: from ?IPV6:2001:8a0:f924:2600:209d:85e2:409e:8726? ([2001:8a0:f924:2600:209d:85e2:409e:8726]) by smtp.gmail.com with ESMTPSA id b5-20020adff905000000b0020a8781be70sm2360781wrr.12.2022.04.29.05.50.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Apr 2022 05:50:45 -0700 (PDT) Message-ID: <3bea5140-e1ef-940d-6a60-0f7864534507@palves.net> Date: Fri, 29 Apr 2022 13:50:44 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: [PATCH 2/2] gdb/remote: return early from remote_check_symbols if waiting for stop reply Content-Language: en-US To: Simon Marchi , gdb-patches@sourceware.org References: <20220424032049.1021263-1-simon.marchi@polymtl.ca> <20220424032049.1021263-3-simon.marchi@polymtl.ca> From: Pedro Alves In-Reply-To: <20220424032049.1021263-3-simon.marchi@polymtl.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Fri, 29 Apr 2022 12:50:49 -0000 On 2022-04-24 04:20, Simon Marchi via Gdb-patches wrote: > What happens is: > > - After doing the "continue" on inferior 1, the remote target gives us > a VFORK_DONE event. The core ignores it and resumes inferior 1. > - Since prune_inferiors is now called after each handled event, in > fetch_inferior_event, it is called after we handled that VFORK_DONE > event and resumed inferior 1. > - Inferior 2 is pruned, which (see backtrace above) causes its program > space to be deleted, which clears the symtabs for that program space, > which calls the new_objfile observable and remote_new_objfile > observer (with a nullptr objfile, to indicate that the previously > loaded symbols have been discarded), which calls > remote_check_symbols. > > remote_check_symbols is the function that sends the qSymbol packet, to > let the remote side ask for symbol addresses. The problem is that the > remote target is working in all-stop / sync mode and is currently > resumed. It has sent a vCont packet to resume the target and is waiting > for a stop reply. It can't send any packets in the mean time. That > causes the exception to be thrown. The inferiors that are pruned, their corresponding processes are gone, otherwise they wouldn't be pruned. So it seems wrong to even send a qSymbol packet at all, as qSymbol on the remote end will be interpreted as "new symbols in the current process", and the remote current process will have nothing to do with the pruned inferior. Note this comment and target_has_execution check: /* Symbol look-up. */ void remote_target::remote_check_symbols () { char *tmp; int end; /* The remote side has no concept of inferiors that aren't running yet, it only knows about running processes. If we're connected but our current inferior is not running, we should not invite the remote target to request symbol lookups related to its (unrelated) current process. */ if (!target_has_execution ()) return; So if we're getting past this check, it seems to me that this means that we're calling remote_check_symbols in the context of some other inferior other than the one that is being pruned, which seems to be to be the bug here. Note a bit below that function does: /* Make sure the remote is pointing at the right process. Note there's no way to select "no process". */ set_general_process (); ... again, this is going to set the remote focus on gdb's current inferior, but that inferior has no relation to the inferior that was pruned, so the remote end is going to be querying symbols for a process that hasn't really changed its symbols. > > This wasn't a problem before, when prune_inferiors was called in > normal_stop, because it was always called at a time the target was not > resumed. > > I realized there are simpler ways to trigger this problem. You only > need to load a symbol file (which triggers remote_check_symbols) while > sync execution is ongoing: > > $ ./gdb -q --data-directory=data-directory -nx a.out \ > -ex "tar ext :1234" \ > -ex "tb main" \ > -ex c \ > -ex "c&" \ > -ex "add-inferior" \ > -ex "inferior 2" \ > -ex "file /bin/ls" > * aborts because of the same exception * > This is a valid problem, but a different problem, IMO.