From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13797 invoked by alias); 3 Mar 2009 02:31:10 -0000 Received: (qmail 13787 invoked by uid 22791); 3 Mar 2009 02:31:09 -0000 X-SWARE-Spam-Status: No, hits=-0.8 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_41,KAM_STOCKGEN,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; Tue, 03 Mar 2009 02:31:04 +0000 Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id n232V1Ee026360 for ; Mon, 2 Mar 2009 18:31:02 -0800 Received: from wf-out-1314.google.com (wfd27.prod.google.com [10.142.4.27]) by wpaz33.hot.corp.google.com with ESMTP id n232UtbN012396 for ; Mon, 2 Mar 2009 18:31:00 -0800 Received: by wf-out-1314.google.com with SMTP id 27so2629549wfd.7 for ; Mon, 02 Mar 2009 18:30:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.143.2.20 with SMTP id e20mr3329110wfi.269.1236047459252; Mon, 02 Mar 2009 18:30:59 -0800 (PST) In-Reply-To: <8ac60eac0902231012lb42bcb1q8b8cf19ad2ac192@mail.gmail.com> References: <20090205030257.8A6073A6B7A@localhost> <8ac60eac0902061837p5885b812j8a26669e799702e1@mail.gmail.com> <8ac60eac0902181458g39dfbce9k63c3329528b0aad5@mail.gmail.com> <20090223010759.GA30997@adacore.com> <8ac60eac0902231012lb42bcb1q8b8cf19ad2ac192@mail.gmail.com> Date: Tue, 03 Mar 2009 02:31:00 -0000 Message-ID: <8ac60eac0903021830w363783ear7d4c8fc1177d6448@mail.gmail.com> Subject: Re: [patch] Fix a crash when displaying variables from shared library. From: Paul Pluzhnikov To: Joel Brobecker Cc: Tom Tromey , Pedro Alves , gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-System-Of-Record: true X-IsSubscribed: yes 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 X-SW-Source: 2009-03/txt/msg00028.txt.bz2 On Mon, Feb 23, 2009 at 10:12 AM, Paul Pluzhnikov wrote: > On Sun, Feb 22, 2009 at 5:07 PM, Joel Brobecker wrote: >>> + for (i = 0; i < d->exp->nelts; i++) >>> + { >>> + union exp_element *elts = d->exp->elts; >>> + if (elts[i].opcode == OP_VAR_VALUE) >> >> I'm afraid this isn't going to work for more complex structures... >> The problem is that you might be reading an undefined field of >> union exp_element. Imagine for instance that you have an expression >> that looks like this: "foo->bar". >> >> At one point, you'll encounter the following elements: >> >> [i ] -> STRUCTOP_PTR >> [i+1] -> A string >> [i+2] -> STRUCTOP_PTR >> >> Iterating over the expression, you'll ignore the element at index i, >> and then check the opcode of the element at i+1, which is the wrong >> field of the enum to access in this case... > > I was afraid of that ... So I just discovered operator_length_standard, which lets me rewrite this loop and avoid this problem: for (i = 0; i < d->exp->nelts; ) { union exp_element *elts = d->exp->elts; int oplen, args; if (elts[i].opcode == OP_VAR_VALUE) { struct block *block = elts[i + 1].block; struct symbol *symbol = elts[i + 2].symbol; struct obj_section *section; gdb_assert (elts[i + 3].opcode == OP_VAR_VALUE); if (block) { const char *const solib_name = solib_address(block->startaddr); if (solib_name && strcmp(solib_name, solib->so_name) == 0) return 1; } section = SYMBOL_OBJ_SECTION (symbol); if (section && section->objfile == solib->objfile) return 1; } operator_length_standard (d->exp, i + 1, &oplen, &args); i += oplen; } I think this will correctly iterate over all elements of the expression, will it not? Unfortunately, this code still crashes, because no_shared_libraries first calls objfile_purge_solibs (which indirectly does obstack_free), and only then clear_solib, which notifies me that the library has already disappeared. When I proceed to use symbol, I am already using dangling obstack :-( Is it ok to move observer notification to before objfile_purge_solibs, or should I add a new notification? Something like: @deftypefun void solib_about_to_be_unloaded (struct so_list *@var{solib}) The shared library specified by @var{solib} is about to be unloaded. @end deftypefun Thanks, -- Paul Pluzhnikov