From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20860 invoked by alias); 4 Jun 2014 13:36:31 -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 20848 invoked by uid 89); 4 Jun 2014 13:36:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.5 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: nm36.bullet.mail.bf1.yahoo.com Received: from nm36.bullet.mail.bf1.yahoo.com (HELO nm36.bullet.mail.bf1.yahoo.com) (72.30.239.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 04 Jun 2014 13:36:29 +0000 Received: from [66.196.81.170] by nm36.bullet.mail.bf1.yahoo.com with NNFMP; 04 Jun 2014 13:36:27 -0000 Received: from [98.139.212.211] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 04 Jun 2014 13:36:27 -0000 Received: from [127.0.0.1] by omp1020.mail.bf1.yahoo.com with NNFMP; 04 Jun 2014 13:36:27 -0000 Received: (qmail 67012 invoked by uid 60001); 4 Jun 2014 13:36:27 -0000 Received: from [137.254.4.5] by web165002.mail.bf1.yahoo.com via HTTP; Wed, 04 Jun 2014 06:36:27 PDT Message-ID: <1401888987.45670.YahooMailNeo@web165002.mail.bf1.yahoo.com> Date: Wed, 04 Jun 2014 13:36:00 -0000 From: Maule Mark Reply-To: Maule Mark Subject: debugging link_map corruption To: "gdb@sourceware.org" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-06/txt/msg00011.txt.bz2 Tried this on libc-help, no response, so trying gdb ... I have a heavily threaded program linked against many (~50) shared librarie= s which occasionally experiences memory corruption such that the link_map l= ist gets trashed rendering the core mostly undebuggable. =A0I'm looking for= ways to debug these sorts of problems. =A0My operating environment is Linu= x. One idea I am experimenting with is to create an audit library which saves = the publicly available link_map (the one exposed through /usr/include/link.= h on Linux) list to a write-protected area upon receipt of a=A0LA_ACT_CONSI= STENT activity callback. =A0The thinking is that if gdb can't follow the li= nk_map from the core, at least I would be able to manually load the .so's a= t their correct addresses from gdb when debugging the 'corrupt' core. =A0In= my current implementation, the audit library has a simple 8k buffer which = it uses to store the public link_map structs in. The problem I'm having with the above, is that I can't figure out how to ex= pose information about the address of the audit library's link_map buffer t= o gdb when debugging the core. =A0I could issue a fprintf from my audit lib= rary to save that information in a file, but it would be much better if I c= ould just figure that out with gdb. =A0I assume the issue is that the audit= library symbols are in a separate namespace. Anyway, I'm looking for guidance on how to gain access to audit library sym= bols from gdb when examining a program core. =A0Additionally, if there are = better ideas for how to attack the problem of corrupt link_map lists in gen= eral, I'd appreciate those as well. Thanks Mark Maule