01:11:44 <rzezeski> Hey all, so I'm having an issue with the zig test suite. They have this thing where they compile various code for different targets and try to run it. If the executable can't exec the test runner will handle that fine. But in this case it's building a static executable with no interpreter specified and that seems to cause us to immediately SIGKILL the process and I think perhaps we are the first platform that does this. So the 
01:11:45 <rzezeski> runner gets confused.
01:12:14 <rzezeski> I could go code spelunking but if anyone could shortcut my knowledge here that would help. As in, the SIGKILL is expected?
01:12:52 <rmustacc> Can you share the elf header for reference?
01:13:12 <rzezeski> That is, the runner can handle exec(2) returning ENOEXEC just fine, but having a SIGKILL delivered is not something it expects
01:13:14 <rzezeski> sure
01:13:21 <rmustacc> And is it really static?
01:13:29 <nbjoerg> if it is really static, no interpreter is fine
01:13:41 <nbjoerg> are you sure it doesn't get killed for executing a random system call?
01:13:43 <rmustacc> Aside from the fact that it probably won't work on us.
01:14:06 <rzezeski> https://gist.github.com/rzezeski/6c4169e3d7085958cf2404e6e5ddb958
01:14:14 <rzezeski> rmustacc: see the comment on that giest
01:14:44 <rmustacc> And it doesn't have a dynamic section I take it?
01:15:18 <rzezeski> nbjoerg: I should rephrase, the test runner is compiling this executable for a linux target and macos target, it then tries to run them, if it gets ENOEXEC then it just ignores it, but we are also delivering a SIGKILL so it reports an error.
01:15:37 <jbk> https://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/exec/elf/elf.c?r=6233c8a8#1046 maybe?
01:15:40 <rzezeski> rmustacc: What would I search for?
01:15:48 <rzezeski> I see no Interpreter section
01:16:22 <rmustacc> It would be elfdump -d, but if it's for another platform that's probably neither here nor there.
01:16:23 <jbk> (and lines 726-741 in the same file)
01:16:40 <rzezeski> yea eldfump -d shows nothing
01:17:05 <rmustacc> We shouldn't be in that because there's no PT_INTERP..
01:17:09 <rmustacc> The 726-741 bit.
01:17:57 <rmustacc> rzezeski: Can you put an fbt on exec_args:return for this?
01:18:36 <rmustacc> The SIGKILL is probably because we got far enough that the child is in an undefined state so it had to kill it and couldn't just drop an ENOEXEC at that point.
01:18:48 <rmustacc> For example, if you were part way through replacing the process image or stack or whatever.
01:20:10 <rmustacc> rzezeski: Actually, also add mapelfexec to that.
01:21:47 <rzezeski> rmustacc: 0 for both
01:26:18 <rzezeski> looks like I'll be writing another blog post here soon, haha
01:28:02 <rmustacc> OK, I have other questions likely, but they'd require the elf object.
01:34:41 <rmustacc> rzezeski: If I was to guess it was that we have a pgrogram header but no PT_INTERP.
01:35:29 <rzezeski> rmustacc: okay, yea I DM'd you a path to the file
01:35:36 <rzezeski> I figure I might have to do some spelunking on this one
01:35:42 <rmustacc> Yeah, it was from looking at that I'm making that guess.
01:35:46 <rzezeski> k
01:35:49 <rzezeski> thank you for looking
01:36:02 <rmustacc> But I don't know for certain.
01:36:23 <rmustacc> Specifically https://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/exec/elf/elf.c?r=6233c8a8#634.
01:37:09 <rmustacc> I was already wrong with other gueses. But most of the rest of that is on having an interpeter.
01:37:25 <rzezeski> what is the uphdr?
01:37:33 <rzezeski> oh
01:37:41 <rzezeski> is that the program header?
01:37:48 <rmustacc> Yes, from mapelfexec.
01:38:01 <rzezeski> cool, well this at least gives me something to look into, so that's great
01:38:45 <rzezeski> Unfortunately my stomach is yelling at me so I need to make dinner now. Thanks for all the help everyone. I'll let you know what I find later.
01:38:58 <rmustacc> So anyways, given how much is going on, I expect that the child process getting killed is unfortunately somewhat reasonable.
01:39:15 <rmustacc> Because it's far enough along and we can't get you back to an ENOEXEC cleanly.
01:39:56 <rmustacc> Doesn't mean we can't maybe figure out sooner or do something different. Just all I know so far.
01:40:48 <rzezeski> We appear to be the first platform acting this way, according to the creator of Zig. FWIW.
01:40:54 <rzezeski> But doesn't mean we are wrong.
01:41:05 <rzezeski> So yea, first step is I need to make sure I understand why it's happening.
01:46:38 <rmustacc> rzezeski: Are they expecting to get an ENOEXEC and for it not to be run or?
01:46:49 <rzezeski> rmustacc: correct
01:46:58 <rmustacc> Based on what property of the elf object?
01:47:05 <rzezeski> I...dunno
01:56:38 <rmustacc> I did confirm you're in this case with DTrace.
01:57:48 <rmustacc> I don't know enough about the expected semantics. If I were to guess the phdr is supposed to have semantics for an interpreter.
10:42:51 <pilonsi> andyf: I didn't know about the strings command, thanks!
10:43:40 <pilonsi> I've noticed I have build errors because I'm running out of space in /tmp
10:43:54 <pilonsi> How big should I make /tmp to be safe for building?
10:44:16 <pilonsi> (And out of curiosity what's the specs of the machines you guys are using to build illumos?)
10:44:25 <andyf> It really is only a superficial check for something like this because it just looks for sequences of printable characters over a certain length. However it clearly shows the original problem and a quick before and after proves things look better now.
10:44:56 <andyf> A more robust approach would be to look at the string table, but I don't think I'd bother unless an advocate comes back and asks for it.
10:45:25 <pilonsi> How could I look at the string table if it was needed? Inspecting the binary?
10:45:43 <andyf> I usually use a VM with at least 16 GiB of RAM, and I limit the number of build threads.. although the illumos.sh is supposed to do that for you based on the amount of installed memory.
10:52:44 <pilonsi> I'm using an OI VM with 8 vcpus and 8GiB RAM running on a bhyve zone in an omnios system which also hosts in which im also hosting a windows vm for other people. The host has 32GiB ram but the windows machine is using 16 and I'm running into hangs if i allocate more memory for my vm (i.e 12GB). I want to investigate that once im more comfortable with the os
10:54:14 <andyf> pilonsi - something like this (this is omnios but OI should also have GNU readelf somewhere)  /usr/gnu/bin/readelf -p .rodata.str1.8 /kernel/misc/amd64/kbtrans
10:55:44 <andyf> (and someone may be a long later to tell me how to do it with native illumos tools :) )
10:55:49 <andyf> *along
10:56:15 <andyf> You can see the embedded tabs in the existing message:
10:56:16 <andyf>   [    a0]  kbtrans_queueevent: Can't allocate ^I^I^I^I^Iblock for event.
11:17:41 <pilonsi> Thanks! I'll look into that as well later as an exercise
14:21:40 <pilonsi> Do you know why nvme disk device names are in the form of c3t00E04C1C0C2F6F08d0 instead of the simpler names sata disks have?
14:23:02 <Woodstock> if an nvme device supports a unique id, that is used for the target number
14:23:55 <Woodstock> similar concept as a SAS WWN, really
14:33:11 <sjorge> WWN's are great
14:38:24 <jbk> and i suspect the reason SATA drives don't is just because we never really exposed it for SATA drives
14:38:51 <jbk> at least until relatively recently
15:25:41 <sjorge> can we get wwn's for sata?
15:26:52 <Woodstock> sure, but can we fix zfs rpool import code to handle device path changes in all possible cases? :)
15:30:21 <jbk> sjorge: yes (if it has one)..
15:30:44 <jbk> previously we weren't translating page 83
15:32:13 <sjorge> so most sata ssd would have one then
15:36:10 <jbk> yeah, probably
15:36:34 <jbk> even a lot of HDDs will as well (I'm guessing most likely really old SATA HDDs would be the ones that don't)
15:42:17 <sommerfeld> Woodstock: main advantage is that the WWN-based names stay the same if you accidentally swap cables around.
15:43:38 <sommerfeld> jbk: all the SATA spinning rust I've plugged into SAS controllers would appear to have WWNs
15:49:11 <jbk> yeah, i'm thinking like _really_ old drives
16:02:56 <Woodstock> hm. pata -> sata bridges perhaps? :)
17:57:58 <gitomat> [illumos-gate] 15910 Favor judgment over judgement -- Dan Cross <cross⊙oc>
18:10:22 <gitomat> [illumos-gate] 11616 Support getaddrinfo() with socktype 0/AI_NUMERICSERV -- Andy Fiddaman <illumos⊙fn>
20:55:31 <richlowe> sommerfeld: so I'm in the libc locale code, for reasons, and I remember you had done stuff there.  Did that ever land?
20:56:21 <richlowe> sommerfeld: and if not, do you remember thinking "Huh, this seems buggy" about anything around the xpg7 bits, especially?
20:58:02 <papertigers> Is there an mdb command that can give me the value at some offset of a pointer? I know you can do the <addr>,40::dump to repeat and dump the data.  But I am looking at a problem where the offset looks differnt in my corefile than what CTF seems to think the real offset is
20:58:35 <richlowe> you can just do math on <addr>
20:58:49 <richlowe> `<addr>+5/J`
20:58:50 <richlowe> or whatever
20:58:53 <papertigers> okay, I was just curious if there was anything built in that would do the math
20:59:02 <papertigers> ahh that makes sense
20:59:03 <papertigers> thanks!
20:59:33 <richlowe> remember the default radix is hex
20:59:40 <richlowe> 0t<blah> for decimal
20:59:48 <papertigers> yup, thanks
21:04:35 <sommerfeld> richlowe: no, I need to get back to that.
21:04:55 <papertigers> I think what I am seeing is a different versions of libssl being pulled into my binary (version 1.x and v 3.x).  So mdb shows me valid data if I do <add>::print SSL session
21:05:18 <papertigers> but the ::dis shows an offset different from ::offsetof SSL session
21:05:18 <sommerfeld> multi-library messes.  ugh.
21:05:25 <jbk> pldd should show if that's happening
21:05:25 <rmustacc> Well, multiple version sis going to be very sad.
21:05:37 <jbk> if you're unsure about that bit
21:06:02 <papertigers> jbk: pldd shows me:
21:06:04 <papertigers> /lib/amd64/libssl.so.3
21:06:06 <papertigers> /opt/local/lib/libssl.so.1.1
21:06:13 <papertigers> which is what tipped me off
21:06:38 <sommerfeld> richlowe: my messing with the locale stuff was excruciatingly localized to optimizing how you find the current locale
21:06:48 <papertigers> so the pkg mediator version vs the pkgin version
21:07:06 <jbk> do you know what version it's supposed to use?
21:07:53 <sommerfeld> papertigers: what is the executable showing this?   you probably need to link it differently or otherwise be more selective about what libraries get pulled in.
21:08:33 <papertigers> sommerfeld: this was a result of me running `cargo install cargo-outdated`
21:08:44 <papertigers> aka a rust binary
21:09:15 <papertigers> and yeah, I just built the binary on a different illumos box that doesn't have pkgin setup and everything works as expected 
21:09:18 <richlowe> I believe the rust crate uses pkgconfig
21:09:50 <richlowe> which probably means it finds the pkgsrc libssl, where something else finds the system one.
21:09:55 <richlowe> ldd -v can help you there
21:17:35 <papertigers> richlowe: yup that makes it pretty clear :) -- the rust binary cargo-outdated requires version OPENSSL_3.0.0 while libcurl that's getting pulled in is depending on OPENSSL_1_1_1
21:20:36 <papertigers> hmm maybe I will turn this into a fun short blog post
21:24:54 <sommerfeld> yeah, build a newer libcurl against openssl 3
21:27:02 <papertigers> the real solution is probably to clean up my dev zone so that all of these deps come from pkg and not a mix of pkg/pkgin
23:32:04 <jbk> or link against a pkgsrc libcurl