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

Hello,

I'm attempting to capture a core-dump file, and gdb reports

warning: core file may not match specified executable file.

And only after installing "dovecot-dbg" on my system (Ubuntu 16.04
LTS)
does gdb report further

warning: the debug information found in "/lib64/ld-2.23.so" does not
match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch).

It took some searching the internet to realize that both messages are
likely the result of having a "stripped" executable:

# file /usr/lib/dovecot/dovecot-lda
/usr/lib/dovecot/dovecot-lda: ELF 64-bit LSB shared object, x86-64,
version 1 (SYSV), dynamically linked, interpreter
/lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32,
BuildID[sha1]=49c9c607c304a5c853c05a4ccb9e4b995f185ac4, stripped

So, how best I am I to obtain a "non-stripped" dovecot-lda executable?

Must I forego my distro's repositories and download the dovecot source,
compiling every executable and all plugins "from scratch", in order to
obtain a useful core-dump file?

Perhaps the bug report instructions at
http://www.dovecot.org/bugreport.html should mention "stripped"
executables and how to avoid them. Perhaps I am simply ignorant, but if
that is the case, there is little to no hope for the "average user"
where submitting bug reports is concerned.

Any guidance would be most appreciated.

Thanks in advance,

-Ben

Sent from my iPhone
> On Sep 13, 2016, at 8:52 PM, Ben Johnson <ben at indietorrent.org>
wrote:
> 
> Hello,
> 
> 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.
> And only after installing "dovecot-dbg" on my system (Ubuntu
16.04 LTS)
> does gdb report further
> 
> warning: the debug information found in "/lib64/ld-2.23.so" does
not
> match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch).
> 
> It took some searching the internet to realize that both messages are
> likely the result of having a "stripped" executable:
> 
> # file /usr/lib/dovecot/dovecot-lda
> /usr/lib/dovecot/dovecot-lda: ELF 64-bit LSB shared object, x86-64,
> version 1 (SYSV), dynamically linked, interpreter
> /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32,
> BuildID[sha1]=49c9c607c304a5c853c05a4ccb9e4b995f185ac4, stripped
> 
> So, how best I am I to obtain a "non-stripped" dovecot-lda
executable?
> 
> Must I forego my distro's repositories and download the dovecot source,
> compiling every executable and all plugins "from scratch", in
order to
> obtain a useful core-dump file?
> 
> Perhaps the bug report instructions at
> http://www.dovecot.org/bugreport.html should mention "stripped"
> executables and how to avoid them. Perhaps I am simply ignorant, but if
> that is the case, there is little to no hope for the "average
user"
> where submitting bug reports is concerned.
> 
> Any guidance would be most appreciated.
> 
> Thanks in advance,
> 
> -Ben

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