From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9785 invoked by alias); 29 Jul 2009 23:56:59 -0000 Received: (qmail 9777 invoked by uid 22791); 29 Jul 2009 23:56:58 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 29 Jul 2009 23:56:49 +0000 Received: from zps37.corp.google.com (zps37.corp.google.com [172.25.146.37]) by smtp-out.google.com with ESMTP id n6TNulhx001039 for ; Wed, 29 Jul 2009 16:56:47 -0700 Received: from qyk6 (qyk6.prod.google.com [10.241.83.134]) by zps37.corp.google.com with ESMTP id n6TNuj6u011569 for ; Wed, 29 Jul 2009 16:56:45 -0700 Received: by qyk6 with SMTP id 6so1677930qyk.11 for ; Wed, 29 Jul 2009 16:56:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.99.66 with SMTP id t2mr94391qcn.38.1248911804490; Wed, 29 Jul 2009 16:56:44 -0700 (PDT) In-Reply-To: <20090728154001.GA19451@caradoc.them.org> References: <20090728154001.GA19451@caradoc.them.org> Date: Wed, 29 Jul 2009 23:56:00 -0000 Message-ID: <8ac60eac0907291656v13f568ebw4f3a2b9bb7c7223d@mail.gmail.com> Subject: Re: Solibs and objfile BFD ownership From: Paul Pluzhnikov To: Paul Pluzhnikov , gdb@sourceware.org Content-Type: multipart/mixed; boundary=0016364eeea876659c046fe0f0cd X-System-Of-Record: true X-IsSubscribed: yes 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 X-SW-Source: 2009-07/txt/msg00237.txt.bz2 --0016364eeea876659c046fe0f0cd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-length: 974 On Tue, Jul 28, 2009 at 8:40 AM, Daniel Jacobowitz wrote: > clear_solib (); > objfile_purge_solibs (); > > The problem with doing things in this order is that both the solib and > the objfile have a reference to the same BFD. The solib is > responsible for releasing it (OBJF_KEEPBFD). arm_objfile_data_cleanup > accesses objfile->obfd during free_objfile, to find the number > of sections; at that point it's already been free'd. That is a problem. > Any thoughts? There doesn't appear to be a correct order of destruction :-( Attached patch restores the original order, while still keeping solib_unloaded observers from accessing danglig objfiles. I do not know if there is a better way to fix this. Tested on Linux/x86_64 with no new regressions. Thanks, -- Paul Pluzhnikov 2009-07-29 Paul Pluzhnikov * solib.c (clear_solib): Rename to clear_solib_1 (clear_solib): New function. (no_shared_libraries): Adjust. --0016364eeea876659c046fe0f0cd Content-Type: text/plain; charset=US-ASCII; name="gdb-clear-solib-20090729.txt" Content-Disposition: attachment; filename="gdb-clear-solib-20090729.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fxqpix3q0 Content-length: 2851 SW5kZXg6IHNvbGliLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmls ZTogL2N2cy9zcmMvc3JjL2dkYi9zb2xpYi5jLHYKcmV0cmlldmluZyByZXZp c2lvbiAxLjEyMgpkaWZmIC11IC1wIC11IC1yMS4xMjIgc29saWIuYwotLS0g c29saWIuYwkxNyBKdWwgMjAwOSAxNzowODoyMyAtMDAwMAkxLjEyMgorKysg c29saWIuYwkyOSBKdWwgMjAwOSAyMzozOToxMSAtMDAwMApAQCAtODkzLDEw ICs4OTMsOCBAQCBzb2xpYl9uYW1lX2Zyb21fYWRkcmVzcyAoQ09SRV9BRERS IGFkZHJlCiAgIHJldHVybiAoMCk7CiB9CiAKLS8qIENhbGxlZCBieSBmcmVl X2FsbF9zeW10YWJzICovCi0KLXZvaWQKLWNsZWFyX3NvbGliICh2b2lkKQor c3RhdGljIHZvaWQKK2NsZWFyX3NvbGliXzEgKGludCBub3RpZnlfb2JzZXJ2 ZXJzKQogewogICBzdHJ1Y3QgdGFyZ2V0X3NvX29wcyAqb3BzID0gc29saWJf b3BzICh0YXJnZXRfZ2RiYXJjaCk7CiAKQEAgLTkyOCw3ICs5MjYsOCBAQCBj bGVhcl9zb2xpYiAodm9pZCkKICAgICB7CiAgICAgICBzdHJ1Y3Qgc29fbGlz dCAqc28gPSBzb19saXN0X2hlYWQ7CiAgICAgICBzb19saXN0X2hlYWQgPSBz by0+bmV4dDsKLSAgICAgIG9ic2VydmVyX25vdGlmeV9zb2xpYl91bmxvYWRl ZCAoc28pOworICAgICAgaWYgKG5vdGlmeV9vYnNlcnZlcnMpCisgICAgICAg IG9ic2VydmVyX25vdGlmeV9zb2xpYl91bmxvYWRlZCAoc28pOwogICAgICAg aWYgKHNvLT5hYmZkKQogCXJlbW92ZV90YXJnZXRfc2VjdGlvbnMgKHNvLT5h YmZkKTsKICAgICAgIGZyZWVfc28gKHNvKTsKQEAgLTkzNyw2ICs5MzYsMTUg QEAgY2xlYXJfc29saWIgKHZvaWQpCiAgIG9wcy0+Y2xlYXJfc29saWIgKCk7 CiB9CiAKKy8qIENhbGxlZCBieSBmcmVlX2FsbF9zeW10YWJzICovCisKK3Zv aWQKK2NsZWFyX3NvbGliICh2b2lkKQoreworICBjbGVhcl9zb2xpYl8xICgx KTsKK30KKworCiAvKiBHTE9CQUwgRlVOQ1RJT04KIAogICAgc29saWJfY3Jl YXRlX2luZmVyaW9yX2hvb2sgLS0gc2hhcmVkIGxpYnJhcnkgc3RhcnR1cCBz dXBwb3J0CkBAIC0xMDE4LDEzICsxMDI2LDIwIEBAIHNoYXJlZGxpYnJhcnlf Y29tbWFuZCAoY2hhciAqYXJncywgaW50IGYKIHZvaWQKIG5vX3NoYXJlZF9s aWJyYXJpZXMgKGNoYXIgKmlnbm9yZWQsIGludCBmcm9tX3R0eSkKIHsKLSAg LyogVGhlIG9yZGVyIG9mIHRoZSB0d28gcm91dGluZXMgYmVsb3cgaXMgaW1w b3J0YW50OiBjbGVhcl9zb2xpYiBub3RpZmllcwotICAgICB0aGUgc29saWJf dW5sb2FkZWQgb2JzZXJ2ZXJzLCBhbmQgc29tZSBvZiB0aGVzZSBvYnNlcnZl cnMgbWlnaHQgbmVlZAotICAgICBhY2Nlc3MgdG8gdGhlaXIgYXNzb2NpYXRl ZCBvYmpmaWxlcy4gIFRoZXJlZm9yZSwgd2UgY2FuIG5vdCBwdXJnZSB0aGUK LSAgICAgc29saWJzJyBvYmpmaWxlcyBiZWZvcmUgY2xlYXJfc29saWIgaGFz IGJlZW4gY2FsbGVkLiAgKi8KKyAgc3RydWN0IHNvX2xpc3QgKnNvID0gc29f bGlzdF9oZWFkOworCisgIC8qIFdlIG5vdGlmeSBhbGwgc29saWJfdW5sb2Fk ZWQgb2JzZXJ2ZXJzIGJlZm9yZSBkZXN0cm95aW5nIGFueSBvYmpmaWxlcywK KyAgICAgYmVjYXVzZSBzb21lIG9ic2VydmVycyBuZWVkIGFjY2VzcyB0byB0 aGVpciBhc3NvY2lhdGVkIG9iamZpbGVzLiAgKi8KKworICBmb3IgKHNvID0g c29fbGlzdF9oZWFkOyBzbzsgc28gPSBzby0+bmV4dCkKKyAgICBvYnNlcnZl cl9ub3RpZnlfc29saWJfdW5sb2FkZWQgKHNvKTsKKworICAvKiBUaGUgb3Jk ZXIgb2YgdGhlIHR3byByb3V0aW5lcyBiZWxvdyBpcyBpbXBvcnRhbnQ6IGNs ZWFyX3NvbGliXzEKKyAgICAgd2lsbCBmcmVlL2Nsb3NlIG9iamZpbGUtPm9i ZmQgKHNvbGliIG93bnMgaXQpLCBidXQgb2JqZmlsZV9wdXJnZV9zb2xpYnMK KyAgICAgbmVlZHMgYWNjZXNzIHRvIGl0IChhdCBsZWFzdCBvbiBBUk0sIHNl ZSBhcm1fb2JqZmlsZV9kYXRhX2NsZWFudXApLiAgKi8KIAotICBjbGVhcl9z b2xpYiAoKTsKICAgb2JqZmlsZV9wdXJnZV9zb2xpYnMgKCk7CisgIGNsZWFy X3NvbGliXzEgKDApOwogfQogCiBzdGF0aWMgdm9pZAo= --0016364eeea876659c046fe0f0cd--