ty everyone, I archived my illumos box and have the files on the vm host

i think it was rmustacc who helped

I have a machine being donated purportedly

and I know there's a net build host, perhaps I should just ask about using that?

Yep build host and distribution packaging are there to help with that :)

*sigh* one of those days when you gcc -o file.c by mistake :)

this is why all my outputs get named foo :)

also somewhat surprising

(again one of those days)

if you build a shared library with gcc, but omit a source

it still generates a (mostly) empty .so file

(well surprising to me since i've not deliberately tried to do this)

you're not omitting source, the CRT etc objects will still be implicitly there

and it will just link them together.

not the most user friendly of viewpoints, but not off the wall

the power to create empty libraries

pmooney: An update on fenix` illumos 14892

fenix illumos 14892

BUG 14892: pollhead lifetime too short in signalfd (In Progress)

↳ illumos.org/issues/14892

1.) Got it to build cleanly on SmartOS (brand hooks in signalfd only change).

2.) Made changes to be pbchk clean and added things to help there as well (e.g. usr/src/pkg and adding the mentioned-but-not-there "common.h").

3.) I have a test program that *might* help induce 14892, but I haven't been able to do it yet. I'm not sure if the program is not going to cause the problem, or if the program needs to get bombarded with more signals, or if I need to apply chill() in the right kernel paths.

Building illumos-gate plus the ~10 changes (your three plus 6 tiny incremental ones and one refactor that makes it easy for SmartOS and OmniOS) to make sure it's a clean build.

pbchk's only complaints on gate are 2022 vs. 2023 ones. :)

Re: 2 - Yeah, that's work I hadn't focused on until the tests were fleshed out

(which is obviously where my effort stalled)

Understood.

I modified one of your tests to do a lot more, but I'm not clear if it's enough to induce the panic.

Lemme put it up on kebe.com for download...

I think andyf (and/or hadfl, I can't recall) was able to get the problem reproduced w/ the postgres test suite

that was, to date, one of the more reliable repros

And Andy tried again this week and COULD NOT DO IT. (It's as if the bug knows we're hunting it now.)

Anyway: kebe.com/~danmcd/webrevs/14892/14892-repro.c

that may be a DEBUG vs non-DEBUG thing

I know I had some trouble getting it to repro as well

it *works*, but it does not, using simple externals, cause a panic yet on a non-debug stock SmartOS.

Good point about DEBUG, however. I've an OmniOS VM setup for just this sort of thing.

postgres may also have tweaked some of the bits

I'll be putting other things into the 14892/ directory on kebe.com as they arise (e.g. SmartOS PI with the fix in it).

I'm going to let the build churn, and come back to it. I wanted to make sure I communicated somewhere about this where you and others can see it.

as far as testing goes, my bigger concern was around ensuring that I hadn't broken signalfd with the change

rather than nailing down a reliable reproducer for 14892 itself

not to say I'd turn one down if it presented itself

Well so far, so good, in that I seem to see them in my test, which is a proper superset of your second one.

I'll be back in 20 or so.

yeah, I just wasn't all that confident yet in the test coverage

lots of edges on signalfd

signals are bastards.

they sure are

signalfd is certainly one less-hairy way of handling them

but it's a bit spicy

It is spicy and they are bastards.

And it built. Now kebe.com/~danmcd/webrevs/14892 has "gate" and "smartos" directories with patch sets to download and look.

(The "smartos" ones Should Just Drop into OmniOS, FWIW.)