https://bugs.exim.org/show_bug.cgi?id=2274
Phil Pennock <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #12 from Phil Pennock <[email protected]> --- The abort server referenced in the crash details has nothing at the claimed URL, and it's three days later, so I would really expect https://retrace.fedoraproject.org/faf/reports/bthash/8fe5b7ec11a15288157804580a2f41dd3fe868d9 to have something if it were ever going to work. So there's nothing there to trace. As far as I can tell, Direct Admin is mostly restricted to those with license keys, which makes it hard to tell what's going on. I've tried seeing how far I could get in a Docker image, but (1) you're running Centos 7.5.1804, which is newer than the latest Centos available on Docker Hub; and (2) the DirectAdmin files mirror I'm looking at does not have packages for "7.5". Meanwhile the crash report doesn't say which version of the package, installed for what architecture, is in use. So at this point we've got a third-party build of Exim, built for unknown OS release, being run on a different OS release, and we have crashes telling us that the death is inside libc, but no stack traces and no way to sanely figure out which version of Exim it was. The bug-report claims that it's Exim 4.91 segfaulting, but the crash report says that it's Exim from the package "da_exim-4.89.1-1". What sort of system is this, where things are failing? Is this running in production somewhere, in this state? We have from the dump a rather poor backtrace which can't tell us much without the binary: : , "frames": : [ { "address": 139775044603071 : , "build_id": "cb4b7554d1adbef2f001142dd6f0a5139fc9aa69" : , "build_id_offset": 634047 : , "function_name": "__strncpy_sse2_unaligned" : , "file_name": "/usr/lib64/libc-2.17.so" : } : , { "address": 4352528 : , "build_id": "bae74c686ca4940655bfcf0c4667e94956fa977b" : , "build_id_offset": 158224 : , "function_name": "main" : , "file_name": "/usr/sbin/exim" : } ] Okay. So somewhere directly in main() there's a call to strncpy; there's no indication of if Exim was compiled such as to optimize away intermediate frames, for example. The only _direct_ call to strncp (via Ustrncpy macro) is when debug-logging, and the initial_cwd is copied into the big-buffer. Perhaps if os_getcwd() fails? Could it be that the spam-checker has chdir()'d to a directory which it unlinks, but calls Exim from inside, so that Exim's os_getcwd() fails? Other than that wild shot in the dark, there's really too little here to chase this any further. -- 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/ ##
