https://bugs.exim.org/show_bug.cgi?id=1671
--- Comment #5 from Wolfgang Breyha <[email protected]> --- Created attachment 828 --> https://bugs.exim.org/attachment.cgi?id=828&action=edit fix SIGSEGV for split_directory I think, I found *one* reason.... first of all it only happens if split_spool_directory = true is used. The patch Phil referred to contains the following for transport.c near exim-4.86/src/transport.c:1755 -------- if (split_spool_directory) - sprintf(CS(buffer + path_len), "%c/%s-D", new_message_id[5], new_message_id); + sprintf(CS spool_file, "%s%c/%s-D", + spool_dir, new_message_id[5], msgq[i].message_id); else - sprintf(CS(buffer + path_len), "%s-D", new_message_id); + sprintf(CS spool_file, "%s%s-D", spool_dir, msgq[i].message_id); -------- In case of split_spool_directory the usage of new_messsage_id[5] is a leftover IMO. On the first run it is an undefined buffer, allocated by transports/smtp.c:smtp_deliver() using uschar new_message_id[MESSAGE_ID_LENGTH + 1]; and "most likely" containing 0 bytes on first run. Used in sprintf it cuts spool_file short to the contents of spool_dir which also means that the following Ustat(spool_file, ...) always succeeds. Using msgq[i].message_id[5] should be correct. See attachment. That fixes the obvious... but IMO there is room for a race. Since the Ustat does not use locking it is still possible that it succeeds on a message which is currently delivered by an other process. So I think further changes are necessary to check for missing spool files and return values in smtp_are_same_identities() not only for split_directory setups. -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
