This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: request for help debugging a segfault in _dl_relocate_object
- From: "Ryan Arnold" <ryan dot arnold at gmail dot com>
- To: "James Washer" <washer at trlp dot com>
- Cc: libc-help at sourceware dot org
- Date: Tue, 29 Apr 2008 15:10:24 -0500
- Subject: Re: request for help debugging a segfault in _dl_relocate_object
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=sgXo27sLlp1XGvktd3QYZPloS4P6BtvS6Kaxu28XXrw=; b=FcATvGWp/lTVGwFNHIwJRdS1HdouoYrg2OMcaoQA6BHOu9nLHfeicgqnvPSno722fSnFSptvHiYk0vz4gQHZ63wlekphBTjzZwjrx2eLINdJ1pXIMZadg9pkMalYd7dmbJaCCU7/nPEEBJcZxeLFoN4jD0NTXNj5YTBEXcNHnK8=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gzOjWyeD/m3nqTxe9o/GyQIbGAfmrZoofLVa9cxl89jmmPKIB8PLo62u0SdDD2t7hOLj5PrzoK9lznWOv4AdT214XEB9pwTmU7OJH64AAZqElK9b4uf8fbOnRjPjBYnMhG0ncKGBj6PadRV4/NFP49VMtpovEdZxKVr9scXAGZ8=
- References: <1209407182.5184.78.camel@p6.trlp1.com>
On Mon, Apr 28, 2008 at 1:26 PM, James Washer <washer@trlp.com> wrote:
> I'm fairly new at digging through libc code and have been trying to
> determine the cause of a segfault in _dl_relocate_object.
>
> On a system running RHEL4U6 we have an application coredump from a
> segfault. glibc-2.3.4-2.38 provides the ld-linux.so that I'm looking at
>
>
>
> The program in question has done a dlopen on
> "/opt/netcool/platform/linux2x86/jre_1.5.4/jre/bin/libawt.so" with flags
> of RTLD_NOW.
>
> Further up the stack (or down the stack if you prefer) we end up in
> _dl_relocate_object and segfault on a null pointer. The pointer in
> question came from
>
>
> const char *strtab = (const void *) D_PTR (l, l_info[DT_STRTAB]);
>
> See near the bottom of this disassembly the comment "BANG" showing the
> instruction that faulted.
>
> Any pointers (no pun intended) as to why l_info[DT_STRTAB] might be null
> would be appreciated.
Hi James,
A backtrace would be useful so that we can determine which invocation
_dl_relocate_object() seg faulted. I'm interested in where the
link_map pointer came from.
Have you tried reproducing this using a more recent GLIBC? Glibc 2.3
is quite old.
Regarding this:
const char *strtab = (const void *) D_PTR (l, l_info[DT_STRTAB]);
What is NULL; the pointer `l' or the value coming out of l_info[DT_STRTAB]?
Unfortunately x86 asm isn't my strong point but I'll help if I can.
Ryan S. Arnold