From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117004 invoked by alias); 20 Feb 2017 10:12:03 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 116990 invoked by uid 89); 20 Feb 2017 10:12:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-wr0-f169.google.com Received: from mail-wr0-f169.google.com (HELO mail-wr0-f169.google.com) (209.85.128.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 20 Feb 2017 10:12:00 +0000 Received: by mail-wr0-f169.google.com with SMTP id 89so56376658wrr.3 for ; Mon, 20 Feb 2017 02:12:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=1Qp0bkMYNfDg7bYMvfy0GjAjdNwBHESzKVkslsynE2k=; b=kICjJiRmCLcrv/E2560trpL2asxPJ0FTyxkDzJbcX9dOchZqQw0LFF44BZ7LOkC9sN R/mQw7sfcmM/W1ur1OqMpxpWu9QvGkuFpZzAgLRUscGepQgoAamh29eoDueyZLRRW5RS TMTadHFgkCN3UTbkpJZS59TpZkEMwPbc99G/gT6Aic+Hfg3bdqwFHbGYAD5n/CvMKsVU W20Fq5Z7d0btcZfEzcbZasoEOX0RmsfXrQeym2nxZKc5Xr7t31D/8ctdXdjZhqO1SEFc cPPVFxLm45L5bY72c7AhCW4P2Yt6zIfXopSiHMIV/TPvGd+/Kjft0nQHEQRJTKB/KEBe T8JQ== X-Gm-Message-State: AMke39kQAnJe5KH3zv25oX1CEJ0+qcyGwkMgGtdVeQGms0CnqDB3nAY2HJbofVtYpP/GKA== X-Received: by 10.223.179.78 with SMTP id k14mr17297314wrd.34.1487585518799; Mon, 20 Feb 2017 02:11:58 -0800 (PST) Received: from [10.0.0.57] (host86-172-174-119.range86-172.btcentralplus.com. [86.172.174.119]) by smtp.gmail.com with ESMTPSA id b87sm12869006wmi.0.2017.02.20.02.11.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Feb 2017 02:11:58 -0800 (PST) To: gdb@sourceware.org From: Matthew Malcomson Subject: Freeing memory allocated in the inferior Message-ID: <6e28ebac-e4de-871a-0b7e-1fef46fc4faf@gmail.com> Date: Mon, 20 Feb 2017 10:12:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2017-02/txt/msg00041.txt.bz2 Hello, I've just been reading the code, and was hoping someone could help me understand something. It seems that memory allocated in the inferior (with `value_allocate_space_in_inferior()` is never freed, even when the gdb process exits/detaches. Is this true (i.e. have I missed something)? I found an old comment on an old bug that implies this is correct https://sourceware.org/bugzilla/show_bug.cgi?id=16236#c1, and the pointer appears to remain valid in the inferior over a lot of allocation after detaching, but neither of those are particularly conclusive. If so, why is this? I can see it would be difficult to know when to free them during execution, because the user may simply remember the pointer address the variable is stored and attempt to use it, but what about storing the allocations on a data structure somewhere, and freeing them when gdb is closing/detaching? I doubt many users are remembering pointer addresses after having detached and attached again to a process, but I guess there could be an extra `set` parameter introduced if this were the case.