dovecot - Sep 2016 - How to obtain a "non-stripped" executable for producing a usable core-dump

On 9/13/2016 10:00 PM, Edgar Pettijohn wrote:
>> I'm attempting to capture a core-dump file, and gdb reports
>> > 
>> > warning: core file may not match specified executable file.
>> > 
> I believe this means the core file doesn't match up to the executable.
I would delete the core and try to reproduce with your new executable then run
gdb with a core that matches.
> 
Thanks so much for the quick reply, Edgar!

That's what I find to be so strange. I am producing the core-dump and
then attempting to run it through gdb immediately thereafter. I just
don't see how the dovecot-lda executable could be changing in the space
of about ten seconds.

I don't know what it's worth, but the "bt full" command, while
at the
gdb prompt, produces legible output. I don't see a bunch of "?"
characters, as cautioned about in the bug report instructions.

For example, here's the tail end of the output (is it usable as-is?):

 session_id = 0x14844a489d8 <error: Cannot access memory at address
0x14844a489d8>,
          session_id_prefix = 0x0, local_ip = {family = 0, u = {ip6 {__in6_u = {
                  __u6_addr8 = '\000' <repeats 15 times>,
__u6_addr16 {0, 0, 0, 0, 0, 0, 0, 0},
                  __u6_addr32 = {0, 0, 0, 0}}}, ip4 = {s_addr = 0}}},
remote_ip = {family = 0, u = {
              ip6 = {__in6_u = {__u6_addr8 = '\000' <repeats 15
times>,
__u6_addr16 = {0, 0, 0, 0,
                    0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, ip4 {s_addr =
0}}},
          local_port = 65320, remote_port = 59489, userdb_fields = 0x0,
          flags_override_add = MAIL_STORAGE_SERVICE_FLAG_DISALLOW_ROOT,
          flags_override_remove = (unknown: 0), no_userdb_lookup = 0}
        storage = 0x1
        user_source = 0x56242ac6d3af ""
        destaddr_source = 0x56242ac6d3af ""
        process_euid = 5000
        stderr_rejection = false
        ret = <optimized out>
        c = <optimized out>
        error = MAIL_ERROR_NONE

Thanks in advance for any additional insight that you may be able to
provide!

-Ben

On 16-09-13 22:05:55, Ben Johnson wrote:
> On 9/13/2016 10:00 PM, Edgar Pettijohn wrote:
> >> I'm attempting to capture a core-dump file, and gdb reports
> >> > 
> >> > warning: core file may not match specified executable file.
> >> > 
> > I believe this means the core file doesn't match up to the
executable. I would delete the core and try to reproduce with your new
executable then run gdb with a core that matches.
> > 
> 
> Thanks so much for the quick reply, Edgar!
> 
> That's what I find to be so strange. I am producing the core-dump and
> then attempting to run it through gdb immediately thereafter. I just
> don't see how the dovecot-lda executable could be changing in the space
> of about ten seconds.
> 
> I don't know what it's worth, but the "bt full" command,
while at the
> gdb prompt, produces legible output. I don't see a bunch of
"?"
> characters, as cautioned about in the bug report instructions.
> 
> For example, here's the tail end of the output (is it usable as-is?):
I've never had lda dump core on me.  If this is just the tail end I'd
say
post the whole thing and see if anyone can help.
> 
>  session_id = 0x14844a489d8 <error: Cannot access memory at address
> 0x14844a489d8>,
>           session_id_prefix = 0x0, local_ip = {family = 0, u = {ip6 >
{__in6_u = {
>                   __u6_addr8 = '\000' <repeats 15 times>,
__u6_addr16 > {0, 0, 0, 0, 0, 0, 0, 0},
>                   __u6_addr32 = {0, 0, 0, 0}}}, ip4 = {s_addr = 0}}},
> remote_ip = {family = 0, u = {
>               ip6 = {__in6_u = {__u6_addr8 = '\000' <repeats 15
times>,
> __u6_addr16 = {0, 0, 0, 0,
>                     0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, ip4 >
{s_addr = 0}}},
>           local_port = 65320, remote_port = 59489, userdb_fields = 0x0,
>           flags_override_add = MAIL_STORAGE_SERVICE_FLAG_DISALLOW_ROOT,
>           flags_override_remove = (unknown: 0), no_userdb_lookup = 0}
>         storage = 0x1
>         user_source = 0x56242ac6d3af ""
>         destaddr_source = 0x56242ac6d3af ""
>         process_euid = 5000
>         stderr_rejection = false
>         ret = <optimized out>
>         c = <optimized out>
>         error = MAIL_ERROR_NONE
> 
> Thanks in advance for any additional insight that you may be able to
> provide!
> 
> -Ben
-- 
Edgar Pettijohn

> On September 14, 2016 at 5:34 AM Edgar Pettijohn <edgar at
pettijohn-web.com> wrote:
> 
> 
> On 16-09-13 22:05:55, Ben Johnson wrote:
> > On 9/13/2016 10:00 PM, Edgar Pettijohn wrote:
> > >> I'm attempting to capture a core-dump file, and gdb
reports
> > >> > 
> > >> > warning: core file may not match specified executable
file.
> > >> > 
> > > I believe this means the core file doesn't match up to the
executable. I would delete the core and try to reproduce with your new
executable then run gdb with a core that matches.
> > > 
> > 
> > Thanks so much for the quick reply, Edgar!
> > 
> > That's what I find to be so strange. I am producing the core-dump
and
> > then attempting to run it through gdb immediately thereafter. I just
> > don't see how the dovecot-lda executable could be changing in the
space
> > of about ten seconds.
> > 
> > I don't know what it's worth, but the "bt full"
command, while at the
> > gdb prompt, produces legible output. I don't see a bunch of
"?"
> > characters, as cautioned about in the bug report instructions.
> > 
> > For example, here's the tail end of the output (is it usable
as-is?):
> 
> I've never had lda dump core on me.  If this is just the tail end
I'd say
> post the whole thing and see if anyone can help.
> 
> > 
> >  session_id = 0x14844a489d8 <error: Cannot access memory at address
> > 0x14844a489d8>,
> >           session_id_prefix = 0x0, local_ip = {family = 0, u = {ip6
> > {__in6_u = {
> >                   __u6_addr8 = '\000' <repeats 15
times>, __u6_addr16 > > {0, 0, 0, 0, 0, 0, 0, 0},
> >                   __u6_addr32 = {0, 0, 0, 0}}}, ip4 = {s_addr = 0}}},
> > remote_ip = {family = 0, u = {
> >               ip6 = {__in6_u = {__u6_addr8 = '\000'
<repeats 15 times>,
> > __u6_addr16 = {0, 0, 0, 0,
> >                     0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, ip4
> > {s_addr = 0}}},
> >           local_port = 65320, remote_port = 59489, userdb_fields =
0x0,
> >           flags_override_add =
MAIL_STORAGE_SERVICE_FLAG_DISALLOW_ROOT,
> >           flags_override_remove = (unknown: 0), no_userdb_lookup = 0}
> >         storage = 0x1
> >         user_source = 0x56242ac6d3af ""
> >         destaddr_source = 0x56242ac6d3af ""
> >         process_euid = 5000
> >         stderr_rejection = false
> >         ret = <optimized out>
> >         c = <optimized out>
> >         error = MAIL_ERROR_NONE
> > 
> > Thanks in advance for any additional insight that you may be able to
> > provide!
> > 
> > -Ben
> 
> -- 
> Edgar Pettijohn
Can you post output of bt full? 

Aki