https://bugs.exim.org/show_bug.cgi?id=2274
Phil Pennock <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|[email protected] |[email protected] Status|NEW |ASSIGNED --- Comment #16 from Phil Pennock <[email protected]> --- I can't speak to the unknown signal issue, but as regards the stack trace: okay, I think I see a problem in the code. I think that if there's a path to a config entry in your trusted configs file [TRUSTED_CONFIG_LIST in Local/Makefile] which is longer than cwd+4, then we'll hit this bug. The logic assumes that the memory store is zeroed out and that a strncpy() will thus leave the copied string with NULs after it until the end of the buffer. There's nothing here which would have us write to bad memory; the problem is going to be that immediately after the bad copy, we walk off it and keep walking, looking for a place to write to. _If_ there's a NUL after the big-buffer, before an unallocated memory region, then we might have issues, but this early in the process lifecycle, that seems unlikely. Alex, I think that you're triggering this because your log_selector includes "arguments", either through "log_selector = +arguments" or "log_selector = +all". As a work-around, you can remove arguments from the list of enabled log features, and you'll no longer trigger this bug. Also, can you confirm that there's a very long path-name in the file which your Local/Makefile's TRUSTED_CONFIG_LIST points to? -- 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/ ##
