From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id EUoDAqSlHmqVki8AWB0awg (envelope-from ) for ; Tue, 02 Jun 2026 05:43:00 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=NJiAQ3oS; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id EE43F1E0A3; Tue, 02 Jun 2026 05:42:59 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 54CB61E062 for ; Tue, 02 Jun 2026 05:42:59 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id BDA234BA2E2C for ; Tue, 2 Jun 2026 09:42:52 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BDA234BA2E2C Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=NJiAQ3oS Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id 0FD2F4BA2E27 for ; Tue, 2 Jun 2026 09:37:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0FD2F4BA2E27 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 0FD2F4BA2E27 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1780393020; cv=none; b=q78RpUReSf48fK/rSeDZ/gNktpeP74+oZzaLTrk4JwaplgQP92T/KFW98Cp2QJnIHDp78GnLvuioiCQc/XX50KjH1ScmhtNN4hdm6MR0WWriRj8cz4AOnvVRywgXnLtTC+cDhuPaxedfYVLGeAART/vSs1zY3k99G7nL//w3H/o= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1780393020; c=relaxed/simple; bh=xGLjX8gAe/VJ/rYwrHpD5TVxt0qctoe1EDWiIlyLnSY=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=QEFAncsyw4RRfNx7TA6luGM3LVM9lJjh1Kxf3/OpBGR4quqFey3LEl2ObcAzUrn9WL0Inzy7oMbwRvRvZS6I1ubAFZ4fZOPXasUHosyLEPbC1yIgcjUxaCFLoNw6j+9+wbS4ls0XRUvxWsjjRi/J5BSieabLrndGyeF2BpDqXUY= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=NJiAQ3oS DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0FD2F4BA2E27 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1780393019; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=w9iCAT65AFpL2BAPF1dG1MuAGZdXpIFOxePtDzvPZ/g=; b=NJiAQ3oSFlfjI9vx3D3l61huZOptWW30xpGaxomJLlm4LdOKdhZZ5qxnQMevuMklYmmzvi pPx3eXKiwFSlAnXTD4bL+KzivgvP+Ugg15SRcO9i4B3pJxSqOJozxdWFeLjaIUOZPxNFwG 3Kt41d0T57OR3XATZJm6r4+VpHJY0Wg= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-625-2pGW-RFTMl6E9Z3k1b66zw-1; Tue, 02 Jun 2026 05:36:58 -0400 X-MC-Unique: 2pGW-RFTMl6E9Z3k1b66zw-1 X-Mimecast-MFC-AGG-ID: 2pGW-RFTMl6E9Z3k1b66zw_1780393017 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-45efa2f7009so1860086f8f.3 for ; Tue, 02 Jun 2026 02:36:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780393017; x=1780997817; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=w9iCAT65AFpL2BAPF1dG1MuAGZdXpIFOxePtDzvPZ/g=; b=oUxVLCGOT3sMsjw0vbRsgDnfeqckSIQ888wCZS7i6rTy/VxWL2GixwVImBvsngudGU L6HB0fBOsrs1ACZIuIFUNpi9A6u39RZyglM3TO8QOHsrGt0YyMuHR+LxDuwJo7+PIpPg 1vbRQhUn+lbay2tik0p6V4qOQPJJyABVoKdWHlT9iA5gKAhXRNLmaynUhuE0doSoAFA1 mFJV7ykFWlN0aRcTDevS4xjcJzLItaOuTy21oHQ2l92lS65UCUshV57R64DnMOwkvvgd ezKLFXV8Z96/hiYu5rWBAS2369DH66+YUSABw2dPc9tdxhRTZ8hKBE9cPWvs2kQ8D0oj Yk1w== X-Gm-Message-State: AOJu0YwuIXQ7muSniS81ZxavhJUcHuy4+1fNFGROLDCwBZ3WUxHx165o seQeTC4ogX/NmmTkZs2gVpzZsnyTZHEakcY5KujGGwLiK8rD4LXAqLWFDY61ju1XqIFNHgjnbr3 dHywN67GFzXwwgAIF4TUXwG5fSPqsyS/1niAN2n0Td1iTpa2qvD/UIu6iE8q35DDIERALL20= X-Gm-Gg: Acq92OEncZGia1oNZgVkDwXIeSGOqWHOY7UpCyArR77O2120vCWZNpWSbhvk+jubazC nuY72dGif2IKCCKzpaeynbjWiwXGD6Wh5qlLm4dfPv+dFUHoSVvDedlrAZXmNG13klIv26Jfymg ifISrEuk1s2C2qR8XbHFsn99jGIWaiQmU6T4KwuOWwRF4G9zNSQPnSpgnjHci+/YieYvkzF3ipv AEUV4mWhlwNOhlu67UWHaih3sVPUR00ygZ4XN6BjHLapzXIctmpfoOlpEYLkiIzut3vwd6nY/a0 MVHJnCm7UY3TuwsqDaSqiPNsHZ1SLU4KiU0KAi5ROOM9K3A1RP2IOwfkmtW3Z5htDloLNZBdOUe B9EVjs3bYHmI+RmSanjrZcy3yHQ== X-Received: by 2002:a05:600c:c492:b0:485:3abe:ab86 with SMTP id 5b1f17b1804b1-490a2900efemr275184805e9.4.1780393017252; Tue, 02 Jun 2026 02:36:57 -0700 (PDT) X-Received: by 2002:a05:600c:c492:b0:485:3abe:ab86 with SMTP id 5b1f17b1804b1-490a2900efemr275184455e9.4.1780393016857; Tue, 02 Jun 2026 02:36:56 -0700 (PDT) Received: from localhost ([213.31.44.43]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-490b0e13eefsm52031945e9.2.2026.06.02.02.36.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jun 2026 02:36:56 -0700 (PDT) From: Andrew Burgess To: Matthieu Longo , Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: [PATCH v1] gdb/python: fix memory leak in gdb_py_tp_name In-Reply-To: <65c7d5c1-37ba-4e49-8d2a-800421075fb2@arm.com> References: <20260526160459.270322-1-matthieu.longo@arm.com> <87fr3e6sdp.fsf@tromey.com> <11b35b46-7e18-471a-94e2-91fef5b287d2@arm.com> <87tsrr5vtl.fsf@tromey.com> <62841b2c-9d0e-4efc-9b26-ca9bfd8787b9@arm.com> <87ldd35php.fsf@tromey.com> <87zf1ixzc9.fsf@redhat.com> <87cxye5pn0.fsf@tromey.com> <65c7d5c1-37ba-4e49-8d2a-800421075fb2@arm.com> Date: Tue, 02 Jun 2026 10:36:55 +0100 Message-ID: <87o6hts2q0.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: U9Eb9ygFK4JxxItycgEhtmyQMw3CGky230ZQtuhrqr4_1780393017 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org Matthieu Longo writes: > On 29/05/2026 14:09, Tom Tromey wrote: >>>>>>> "Andrew" == Andrew Burgess writes: >> >> Andrew> isn't throwing an error here going to be problematic as gdb_py_tp_name >> Andrew> is called from Python callbacks? Unless these are catching and handling >> Andrew> exceptions then the error is going to end up trying to pass through >> Andrew> Python's C code. >> >> Yeah. >> >> I guess maybe it isn't explicitly stated anywhere (not sure) but the >> rule in gdb's Python layer is that gdb exceptions can't propagate into >> Python itself. So if a function is called from Python (say like a >> __repr__ implementation), then that function has to be sure that it does >> not throw. And since most things in gdb can throw, this is why at >> present we wrap calls into gdb's core in try/catch. >> >> Andrew> So maybe just returning something like "" would >> Andrew> be better? This might be better even when the safety work _is_ merged; >> Andrew> if gdb_py_tp_name is called as part of logging then we'd probably rather >> Andrew> log "" than have GDB throw an exception? >> >> Yeah, I think this is what should be done, since IIUC the cases where >> this can set the Python exception are pathological in nature. >> >> Or just propagating the Python exception. Though this would mean using >> a return type other than std::string. >> >> Tom > > Adopting the approach proposed by Andrew. > > Matthieu > > /* Return the type's fully qualified name from a PyTypeObject. */ > -const char * > +std::string > gdb_py_tp_name (PyTypeObject *py_type) noexcept > { > + static const std::string NO_TYPE_NAME = ""; > + > + auto pyobj_to_str = [&](PyObject *name) -> std::string > + { > + const char *s = PyUnicode_AsUTF8AndSize (name, nullptr); > + if (s == nullptr) > + return NO_TYPE_NAME; If PyUnicode_AsUTF8AndSize fails then a Python exception will be set. As we're not going to propagate that back to the actual Python interpreter, should we not clear the exception at this point? And the same question each time NO_TYPE_NAME is injected instead of an error? Thanks, Andrew