From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20122 invoked by alias); 4 Sep 2009 15:25:51 -0000 Received: (qmail 20099 invoked by uid 22791); 4 Sep 2009 15:25:50 -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; Fri, 04 Sep 2009 15:25:44 +0000 Received: from zps76.corp.google.com (zps76.corp.google.com [172.25.146.76]) by smtp-out.google.com with ESMTP id n84FPgwZ005602 for ; Fri, 4 Sep 2009 08:25:42 -0700 Received: from yxe27 (yxe27.prod.google.com [10.190.2.27]) by zps76.corp.google.com with ESMTP id n84FPWuQ013369 for ; Fri, 4 Sep 2009 08:25:40 -0700 Received: by yxe27 with SMTP id 27so2528954yxe.10 for ; Fri, 04 Sep 2009 08:25:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.26.6 with SMTP id d6mr12567450anj.149.1252077940025; Fri, 04 Sep 2009 08:25:40 -0700 (PDT) In-Reply-To: <8ac60eac0909030854j21d514f9h5047a099a3eb3d80@mail.gmail.com> References: <20090902164425.GR4379@adacore.com> <8ac60eac0909030854j21d514f9h5047a099a3eb3d80@mail.gmail.com> Date: Fri, 04 Sep 2009 15:25:00 -0000 Message-ID: <8ac60eac0909040825u25ce064co34550210ec2e5f11@mail.gmail.com> Subject: Re: [gdb-7.0 release] 2009-09-02 status and proposed plan From: Paul Pluzhnikov To: Joel Brobecker Cc: gdb@sourceware.org, Tom Tromey , Doug Evans Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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-09/txt/msg00070.txt.bz2 On Thu, Sep 3, 2009 at 8:54 AM, Paul Pluzhnikov wro= te: > I think elimination of failing asserts: > =A0http://sourceware.org/ml/gdb-patches/2009-09/msg00062.html > should be considered release blocking. I think there is another release blocker: For the last two weeks we've been running with a beta release built on 20090824 from CVS Head, and have several (more than 20) reports of SIGSGV in GDB, when restarting the inferior. Yesterday I got a repro and analyzed it. AFAICT, the problem is that in (recently added) clean_up_objfile_types, we make copies of types from unloaded solibs. Names of these types come from the .debug_info of the corresponding solib. If solib is small, its .debug_info is obstack_alloc()ed and still valid at the time of clean_up_objfile_types call. If it is large, it gets bfd_mmap()ed in dwarf2_read_section(), and is munmapped in dwarf2_per_objfile_cleanup, which executes *before* clean_up_objfile_types. By the time we come to strdup in copy_type_recursive (called from clean_up_objfile_types), the name of the type has been munmapped. Here is the crash stack (sorry about gmail line wrapping): #0 0x00007f0c16a60a30 in strlen () from /usr/lib64/libc.so.6 #1 0x000000000062f896 in xstrdup (s=3D0x7f0c0ef9ce64
) at ../../../depot2/gcctools/google_vendor_src_branch/gdb/gdb-7.0.x-beta/libibe= rty/xstrdup.c:33 #2 0x00000000004e5769 in copy_type_recursive (objfile=3D, type=3D0x17f2a3b8, copied_types=3D0x17ec8f60) at ../../../depot2/gcctools/google_vendor_src_branch/gdb/gdb-7.0.x-beta/= gdb/gdbtypes.c:2877 #3 0x000000000047200b in clean_up_objfile_types (objfile=3D0x8903b80, datum=3D) at ../../../depot2/gcctools/google_vendor_src_branch/gdb/gdb-7.0.x-beta/= gdb/python/python-type.c:548 #4 0x000000000040300b in clear_objfile_data (objfile=3D0x8903b80) at ../../../depot2/gcctools/google_vendor_src_branch/gdb/gdb-7.0.x-beta/gdb/ob= jfiles.c:1036 #5 0x0000000000403a56 in objfile_free_data (objfile=3D0x8903b80) at ../../../depot2/gcctools/google_vendor_src_branch/gdb/gdb-7.0.x-beta/gdb/ob= jfiles.c:1019 #6 free_objfile (objfile=3D0x8903b80) at ../../../depot2/gcctools/google_vendor_src_branch/gdb/gdb-7.0.x-beta/gdb/ob= jfiles.c:453 #7 0x0000000000403bec in objfile_purge_solibs () at ../../../depot2/gcctools/google_vendor_src_branch/gdb/gdb-7.0.x-beta/gdb/ob= jfiles.c:758 #8 0x00000000004f0545 in target_pre_inferior (from_tty=3D0) at ../../../depot2/gcctools/google_vendor_src_branch/gdb/gdb-7.0.x-beta/gdb/ta= rget.c:1897 #9 0x00000000004c1b4c in run_command_1 (args=3D0x0, from_tty=3D0, tbreak_at_main=3D0) at ../../../depot2/gcctools/google_vendor_src_branch/gdb/gdb-7.0.x-beta/gdb/in= fcmd.c:482 The 0x7f0c0ef9ce64 used to point to "int32" in a DWARF2 section which has since been removed/unmapped. I am still working on a stand-alone repro case. --=20 Paul Pluzhnikov