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 , session_id_prefix = 0x0, local_ip = {family = 0, u = {ip6 = {__in6_u = { __u6_addr8 = '\000' , __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' , __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 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 , session_id_prefix = 0x0, local_ip = {family = 0, u = {ip6 = {__in6_u = { __u6_addr8 = '\000' , __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' , __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