From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3525 invoked by alias); 25 Jan 2018 22:24:44 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 3512 invoked by uid 89); 25 Jan 2018 22:24:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=H*u:6.1, H*UA:6.1 X-HELO: userp2130.oracle.com Received: from userp2130.oracle.com (HELO userp2130.oracle.com) (156.151.31.86) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 25 Jan 2018 22:24:42 +0000 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w0PMLwTH007054; Thu, 25 Jan 2018 22:24:36 GMT Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2130.oracle.com with ESMTP id 2fqqqfr2rj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 25 Jan 2018 22:24:36 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w0PMOZMo004278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 25 Jan 2018 22:24:35 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w0PMOZ50011303; Thu, 25 Jan 2018 22:24:35 GMT Received: from [10.159.156.69] (/10.159.156.69) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 25 Jan 2018 14:24:35 -0800 Subject: Re: [PATCH PR gdb/20057] Internal error on trying to set {char[]}$pc="string" To: Joel Brobecker Cc: gdb-patches@sourceware.org References: <1516844738-79996-1-git-send-email-weimin.pan@oracle.com> <20180125041431.tghhxefsgxnxh3l3@adacore.com> From: Wei-min Pan Message-ID: <1dfc87b0-353d-3388-a427-fee247dc79a5@oracle.com> Date: Thu, 25 Jan 2018 22:24:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180125041431.tghhxefsgxnxh3l3@adacore.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8785 signatures=668655 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801250293 X-SW-Source: 2018-01/txt/msg00542.txt.bz2 On 1/24/2018 8:14 PM, Joel Brobecker wrote: >> To support C99 VLA, function value_from_contents_and_address() was >> modified to add a call to resolve_dynamic_type(), which in turn >> calls resolve_dynamic_array() to resolve the dynamic array bounds >> to static values. But the problem arises when function copy_type(), >> called by resolve_dynamic_array(), expects the type to be copied >> to have an associated objfile from which the new type is allocated, >> or asserts. Since type char[] doesn't have an associated objfile >> when the following gdb command: >> >> (gdb) set {char[]}$pc="hello" >> >> was issued, gdb asserts. >> >> The gdb_assert (TYPE_OBJFILE_OWNED (type)) line in copy_type() doesn't >> look necessary or correct since space needed for the new type could be >> allocated from either the type's objfile if it exists or gdbarch if >> it doesn't, similar to what alloc_type_copy(), which is called after >> gdb_assert() in copy_type(), does. Removing gdb_assert() fixes the >> problem. > I think removing the assert just shifts the issue elsewhere. > Basically, you want the lifetime of the new type to match > the lifetime of the object using it. The gdbarch structure > has a lifetime that's different from objfiles. Is there any reason why the gdbarch structure, which won't be freed until the corresponding architecture is, needs to have a lifetime that matches the objfiles? > I happen to have hit the same issue as you, but from an Ada expression, > and sent it a fix not long ago: > https://www.sourceware.org/ml/gdb-patches/2018-01/msg00240.html > > Does it fix your problem too? > Yes, it does fix my problem of gdb asserting on the "set {char[]}$pc="hi"" command, as reported in the PR, but still asserts on a slightly modified "set {unsigned char[]}$pc="hi" command. Thanks.