This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
RE: pc 0x25c9b0 in read in psymtab, but not in symtab
- From: "Elmenthaler, Jens" <jens dot elmenthaler at verigy dot com>
- To: <gdb at sourceware dot org>
- Date: Mon, 11 Jan 2010 02:46:01 -0600
- Subject: RE: pc 0x25c9b0 in read in psymtab, but not in symtab
> I'm running out of time, right now. But a guess a program that dlopen's a > shared library could be good candidate. I will give it a try as soon as < > possible.
I can no longer reproduce the problem: the reason can be one of the following thing:
- I rebooted my linux machine
- completely recompiled my software
I guess the trigger was the second, so I think the problem is sitting between keyboard and chair.
Jens.
-----Original Message-----
From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On Behalf Of Elmenthaler, Jens
Sent: Freitag, 8. Januar 2010 17:32
To: Tristan Gingold; Chris Sutcliffe
Cc: gdb@sourceware.org
Subject: RE: pc 0x25c9b0 in read in psymtab, but not in symtab
> Sadly, without reproducer I won't get far.
In my case, the addresses complained about resolves to the following locations (RedHat Enterprise Linux 5.3):
maint translate-address 0x25c9b0
-> _dl_debug_state + 0 in section .text of /lib/ld-linux.so.2
maint translate-address 0x25c9b1
-> _dl_debug_state + 1 in section .text of /lib/ld-linux.so.2
This makes perfectly sense, as I see the messages while (or shortly after) the gdb is stopped because of shared library event.
I'm running out of time, right now. But a guess a program that dlopen's a shared library could be good candidate. I will give it a try as soon as possible.
Jens.
-----Original Message-----
From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On Behalf Of Tristan Gingold
Sent: Freitag, 8. Januar 2010 16:56
To: Chris Sutcliffe
Cc: gdb@sourceware.org
Subject: Re: pc 0x25c9b0 in read in psymtab, but not in symtab
On Jan 8, 2010, at 4:42 PM, Chris Sutcliffe wrote:
>> yes this bug I encounter some time ago, too. It is related to DLL files
>> not having any debugging information but are shown in backtrace. Here it
>> warns once about psymtab != symtab and code in gdb fix it afterwards. IMHO
>> this warning is simply pretty bogus here, or the DLL loader should
>> generate for pe-coff the symtab, too.
>
> Hopefully this is helpful.
Not that much. This doesn't sound coherent to me because if there is no debugging information both the
psymtab and the symtab should be empty.
> If there is anything else I can do to help track down the bug, please
> let me know.
It would be nice to have a reproducer. It doesn't need to be small and I think sources are not needed
to investigate this issue.
Sadly, without reproducer I won't get far.
Tristan.