From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16912 invoked by alias); 27 May 2009 23:47:08 -0000 Received: (qmail 16897 invoked by uid 22791); 27 May 2009 23:47:06 -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, 27 May 2009 23:47:02 +0000 Received: from spaceape23.eur.corp.google.com (spaceape23.eur.corp.google.com [172.28.16.75]) by smtp-out.google.com with ESMTP id n4RNkxvk016959 for ; Wed, 27 May 2009 16:46:59 -0700 Received: from qyk6 (qyk6.prod.google.com [10.241.83.134]) by spaceape23.eur.corp.google.com with ESMTP id n4RNkutx007506 for ; Wed, 27 May 2009 16:46:57 -0700 Received: by qyk6 with SMTP id 6so7939674qyk.28 for ; Wed, 27 May 2009 16:46:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.84.209 with SMTP id k17mr508039qcl.61.1243468016456; Wed, 27 May 2009 16:46:56 -0700 (PDT) In-Reply-To: <1243457555.17311.4.camel@localhost.localdomain> References: <1243457555.17311.4.camel@localhost.localdomain> Date: Wed, 27 May 2009 23:47:00 -0000 Message-ID: <8ac60eac0905271646g2a775639sbe9a97d587fdc943@mail.gmail.com> Subject: Re: examining a core dump on a machine with other base addresses in shared libraries From: Paul Pluzhnikov To: Drago Krznaric Cc: gdb@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-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-05/txt/msg00173.txt.bz2 On Wed, May 27, 2009 at 1:52 PM, Drago Krznaric wrote: > I have a program and a core dump created on machine A that I copy to > machine B. I can open the core dump and get a nice backtrace on A but > not on B. The reason appears to be that the shared libraries on A and B > have different base addresses. They are otherwise exactly identical in > hardware and software (RedHat 4). Are you absolutely sure the libc binaries are identical between A and B? We see a lot of similar GDB failures due to mismatch between libc versions (but we don't use prelink). You could verify whether prelink is the problem, by copying B:libc.so.6 and B:ld-linux.so.2 to e.g. /tmp/lib, manually prelinking them to the same address A:libc.so.6 and A:ld-linux.so.2 were prelinked at, and verifying they "work" (set solib-absolute-prefix /tmp in GDB before loading the core). I think you should also get identical (as in md5sum-identical) binary for B:/tmp/lib/libc.so.6 and A:/lib/libc.so.6 Cheers, -- Paul Pluzhnikov