public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* Re: Get Different Result for the same core file with different versions of gdb.
       [not found] <CAKU4AWpCgnZyOjMWW5XMYKQvMosRFX1r1OadJ42AoXW7cNnw8A@mail.gmail.com>
@ 2021-02-02  2:15 ` Andy Fan
  2021-02-02 15:30   ` Simon Marchi
  0 siblings, 1 reply; 4+ messages in thread
From: Andy Fan @ 2021-02-02  2:15 UTC (permalink / raw)
  To: gdb

On Mon, Feb 1, 2021 at 11:57 AM Andy Fan <zhihui.fan1213@gmail.com> wrote:

> Hi:
>
> You can pay attention to $2 and $3.They check the same addr in the same
> core file.
> I'm sure I am debugging the same file in the same machine.
>
> GDB 7.6:
>
> (gdb) up 3
> #3  ResetPlanCache () at plancache.c:1922
> 1922 plancache.c: No such file or directory.
> (gdb) p ((AllocSet)plansource->query_context)->freelist
> $1 = {0x0, *0x5bdd3b8*, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}
> (gdb) p *((AllocSet)plansource->query_context)->freelist[1]
> *$2 = {size = 10649824, aset = 0xa283c0 <AllocSetFree>}*
> (gdb) p plansource->query_context->name
> *$3 = 0xbfd929 "unnamed prepared statement"*
> (gdb) x /10c plansource->query_context->name
> 0xbfd929: 117 'u' 110 'n' 110 'n' 97 'a' 109 'm' 101 'e' 100 'd' 32 ' '
> 0xbfd931: 112 'p' 114 'r'
> (gdb) quit
>
>
> GDB  9.2:
> (gdb) up 3
> #3  ResetPlanCache () at plancache.c:1922
> 1922 plancache.c: No such file or directory.
> (gdb) p ((AllocSet)plansource->query_context)->freelist
> $1 = {0x0, *0x5bdd3b8*, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}
> (gdb) p *((AllocSet)plansource->query_context)->freelist[1]
> *$2 = {size = 16, aset = 0x0}*
> (gdb) p plansource->query_context->name
> *$3 = 0xbfd929 ""*
> (gdb) x /10c plansource->query_context->name
> 0xbfd929: 0 '\000' 0 '\000' 0 '\000' 0 '\000' 0 '\000' 0 '\000' 0 '\000' 0
> '\000'
> 0xbfd931: 0 '\000' 0 '\000'
>
>
> Any ideas? Thanks!
>
> --
> Best Regards
> Andy Fan
>

Will it have something with compiler?  The compiler I used
to build the software (which generated the core file) is LLVM 6.0.0.



-- 
Best Regards
Andy Fan (https://www.aliyun.com/)

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Get Different Result for the same core file with different versions of gdb.
  2021-02-02  2:15 ` Get Different Result for the same core file with different versions of gdb Andy Fan
@ 2021-02-02 15:30   ` Simon Marchi
  2021-02-03  2:56     ` Andy Fan
  0 siblings, 1 reply; 4+ messages in thread
From: Simon Marchi @ 2021-02-02 15:30 UTC (permalink / raw)
  To: Andy Fan, gdb



On 2021-02-01 9:15 p.m., Andy Fan via Gdb wrote:
> On Mon, Feb 1, 2021 at 11:57 AM Andy Fan <zhihui.fan1213@gmail.com> wrote:
> 
>> Hi:
>>
>> You can pay attention to $2 and $3.They check the same addr in the same
>> core file.
>> I'm sure I am debugging the same file in the same machine.
>>
>> GDB 7.6:
>>
>> (gdb) up 3
>> #3  ResetPlanCache () at plancache.c:1922
>> 1922 plancache.c: No such file or directory.
>> (gdb) p ((AllocSet)plansource->query_context)->freelist
>> $1 = {0x0, *0x5bdd3b8*, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}
>> (gdb) p *((AllocSet)plansource->query_context)->freelist[1]
>> *$2 = {size = 10649824, aset = 0xa283c0 <AllocSetFree>}*
>> (gdb) p plansource->query_context->name
>> *$3 = 0xbfd929 "unnamed prepared statement"*
>> (gdb) x /10c plansource->query_context->name
>> 0xbfd929: 117 'u' 110 'n' 110 'n' 97 'a' 109 'm' 101 'e' 100 'd' 32 ' '
>> 0xbfd931: 112 'p' 114 'r'
>> (gdb) quit
>>
>>
>> GDB  9.2:
>> (gdb) up 3
>> #3  ResetPlanCache () at plancache.c:1922
>> 1922 plancache.c: No such file or directory.
>> (gdb) p ((AllocSet)plansource->query_context)->freelist
>> $1 = {0x0, *0x5bdd3b8*, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}
>> (gdb) p *((AllocSet)plansource->query_context)->freelist[1]
>> *$2 = {size = 16, aset = 0x0}*
>> (gdb) p plansource->query_context->name
>> *$3 = 0xbfd929 ""*
>> (gdb) x /10c plansource->query_context->name
>> 0xbfd929: 0 '\000' 0 '\000' 0 '\000' 0 '\000' 0 '\000' 0 '\000' 0 '\000' 0
>> '\000'
>> 0xbfd931: 0 '\000' 0 '\000'
>>
>>
>> Any ideas? Thanks!
>>
>> --
>> Best Regards
>> Andy Fan
>>
> 
> Will it have something with compiler?  The compiler I used
> to build the software (which generated the core file) is LLVM 6.0.0.

At first glance, it sounds like a bug.  Can you provide a reproducer?

Simon

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Get Different Result for the same core file with different versions of gdb.
  2021-02-02 15:30   ` Simon Marchi
@ 2021-02-03  2:56     ` Andy Fan
  2021-02-03 15:29       ` Simon Marchi
  0 siblings, 1 reply; 4+ messages in thread
From: Andy Fan @ 2021-02-03  2:56 UTC (permalink / raw)
  To: Simon Marchi; +Cc: gdb

On Tue, Feb 2, 2021 at 11:31 PM Simon Marchi <simon.marchi@polymtl.ca>
wrote:

>
>
> On 2021-02-01 9:15 p.m., Andy Fan via Gdb wrote:
> > On Mon, Feb 1, 2021 at 11:57 AM Andy Fan <zhihui.fan1213@gmail.com>
> wrote:
> >
> >> Hi:
> >>
> >> You can pay attention to $2 and $3.They check the same addr in the same
> >> core file.
> >> I'm sure I am debugging the same file in the same machine.
> >>
> >> GDB 7.6:
> >>
> >> (gdb) up 3
> >> #3  ResetPlanCache () at plancache.c:1922
> >> 1922 plancache.c: No such file or directory.
> >> (gdb) p ((AllocSet)plansource->query_context)->freelist
> >> $1 = {0x0, *0x5bdd3b8*, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}
> >> (gdb) p *((AllocSet)plansource->query_context)->freelist[1]
> >> *$2 = {size = 10649824, aset = 0xa283c0 <AllocSetFree>}*
> >> (gdb) p plansource->query_context->name
> >> *$3 = 0xbfd929 "unnamed prepared statement"*
> >> (gdb) x /10c plansource->query_context->name
> >> 0xbfd929: 117 'u' 110 'n' 110 'n' 97 'a' 109 'm' 101 'e' 100 'd' 32 ' '
> >> 0xbfd931: 112 'p' 114 'r'
> >> (gdb) quit
> >>
> >>
> >> GDB  9.2:
> >> (gdb) up 3
> >> #3  ResetPlanCache () at plancache.c:1922
> >> 1922 plancache.c: No such file or directory.
> >> (gdb) p ((AllocSet)plansource->query_context)->freelist
> >> $1 = {0x0, *0x5bdd3b8*, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}
> >> (gdb) p *((AllocSet)plansource->query_context)->freelist[1]
> >> *$2 = {size = 16, aset = 0x0}*
> >> (gdb) p plansource->query_context->name
> >> *$3 = 0xbfd929 ""*
> >> (gdb) x /10c plansource->query_context->name
> >> 0xbfd929: 0 '\000' 0 '\000' 0 '\000' 0 '\000' 0 '\000' 0 '\000' 0
> '\000' 0
> >> '\000'
> >> 0xbfd931: 0 '\000' 0 '\000'
> >>
> >>
> >> Any ideas? Thanks!
> >>
> >> --
> >> Best Regards
> >> Andy Fan
> >>
> >
> > Will it have something with compiler?  The compiler I used
> > to build the software (which generated the core file) is LLVM 6.0.0.
>
> At first glance, it sounds like a bug.  Can you provide a reproducer?
>
> Simon
>

Hi Simon:
  Thanks for your reply!  Actually I am debugging postgresql bug, however
I can't reproduce the core at last,  so the simple answer for your question
is
no, I can't provide the reproducer. I'm sorry about that.  But if you want
any
further analysis on the current core file,  I can try my best.

-- 
Best Regards
Andy Fan (https://www.aliyun.com/)

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Get Different Result for the same core file with different versions of gdb.
  2021-02-03  2:56     ` Andy Fan
@ 2021-02-03 15:29       ` Simon Marchi
  0 siblings, 0 replies; 4+ messages in thread
From: Simon Marchi @ 2021-02-03 15:29 UTC (permalink / raw)
  To: Andy Fan; +Cc: gdb

> Hi Simon:
>   Thanks for your reply!  Actually I am debugging postgresql bug, however
> I can't reproduce the core at last,  so the simple answer for your question is
> no, I can't provide the reproducer. I'm sorry about that.  But if you want any
> further analysis on the current core file,  I can try my best. 

I don't know core file handling well enough to provide you with
precise instructions to guide you.  If I had that it front of me, I
would probably check which address GDB is trying to read (if it's the
same in both cases).  I would inspect the LOAD program headers of the
core file, see what's the content at that address.  If I find that GDB
indeed is not reading the right content, I would try to bridge the gap
between where LOAD program headers from the core file are processed and
where memory is read in GDB, to try to find where the chain is broken.

The relevant code for that is probably in gdb/corelow.c.

Simon

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-02-03 15:30 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <CAKU4AWpCgnZyOjMWW5XMYKQvMosRFX1r1OadJ42AoXW7cNnw8A@mail.gmail.com>
2021-02-02  2:15 ` Get Different Result for the same core file with different versions of gdb Andy Fan
2021-02-02 15:30   ` Simon Marchi
2021-02-03  2:56     ` Andy Fan
2021-02-03 15:29       ` Simon Marchi

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).