Allowlist the patterns we can handle when searching for core files

[asomers]

The kern.corefile sysctl can control the name and location of corefiles on FreeBSD. It would be great if kyua_stacktrace_find_core could grok that sysctl. Its format is documented here: https://www.freebsd.org/cgi/man.cgi?query=core

[jmmv]

I know I mentioned this elsewhere but I can't remember where that was now.

I think it'd make sense to move this "find core file" functionality to a function shipped by the OS, possibly in libutil, so that Kyua didn't have to implement parsing of such super-OS-specific details. (If we'd get this added to FreeBSD and NetBSD only, I'd be pleased already.)

[jmmv]

Been thinking about this today and got to the conclusion that such an API cannot be implemented reliably nor can Kyua implement something that works in all cases.

The core names may depend on more than just the binary name or the PID: they can also include, for example, the UID of the process. And, when we wait(2), we don't know what the subprocess may have done so we may not be able to find the core file at all.

Even worse: Linux can pipe the core file to a given application as mentioned in #121 and so there is nothing we can do in that case to catch it.

The option of setting the kern.corefile to a known value so that we know deterministically where core files are dumped is in general not feasible because we cannot make Kyua touch a system-wide setting. However, this would be doable in NetBSD because it supports per-process core filename settings (though I haven't validated if non-root can modify them).

I don't also fancy the idea of being in the game of reimplementing kern.corefile parsing given that this is very OS-specific and we cannot get it to work in 100% of the cases. We could handle the PID placeholder (with its various different names in different OSes), but that's about it.

So, what I'm going to do for now is: commit to supporting the default core name patterns supplied by the OSes we are interested in. If we fail to locate the core file, then print a descriptive error message saying what the likely cause is. And change the manual pages to describe this behavior in detail.

In the future, we might want to implement some form of parsing for simple pattern options.

[jmmv]

Let's make this more generic. We should whitelist the patterns that we can support (say pathnames with at most the process name and PIDs bundled in them) and use those when searching for the core file. Then we can differentiate between the two possible cases of "cannot find core file" vs. "we have no clue how to find the core file".

[rodrigc]

On OS X, core files get put in /cores/ by default, so the kyua tests for core files fail.

Luckily, OS X follows a BSD-ish way of specifying where corefiles go via sysctl:

kern.corefile = /cores/core.%P kern.coredump = 1 kern.sugid_coredump = 0 kern.corefile: /cores/core.%P kern.coredump: 1

[jmmv]

rodrigc, Kyua already has support for OS X's default naming scheme: https://github.com/jmmv/kyua/blob/master/testers/stacktrace.c#L265 . Is that not working for you?

[rodrigc]

Hi,

For whatever reason, when I submitted the Homebrew recipe, I originally had "make check" ad "make installcheck" as part of the build/installation process. I had to remove those steps because they were failing on OS X in the corefile tests. Those steps were failing in the automated system that Homebrew uses to build packages. In the interest of moving things along and getting into Homebrew, I removed those steps from the recipe. I didn't have time to dig into it further than that.

[ngie-eign]

This functionality unfortunately doesn't work 100% on modern Linux either because of how it handles core file writing..