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@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
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@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
On 9/14/2016 12:31 AM, Aki Tuomi wrote:
Can you post output of bt full?
Aki
Sure! It seems better suited to pastebin:
Thanks for any help!
-Ben
participants (3)
-
Aki Tuomi
-
Ben Johnson
-
Edgar Pettijohn