robertdfrench I don't recognise the error, but then I use gdb extremely rarely so I wouldn't see it. I mostly debug things with mdb and dtrace.

I'm glad it seems to be a general upstream problem though!

anyone have any ideas on tracking stuff w/ dtrace across the zio pipeline and scheduler?

i'm going to file a bug for this, but in some testing, we've been able to identify a workload that can cause zpool corruption when using zpool trim

looking at the trim code, i've found a pretty sensible explanation, and with the obvious fix, the corruption goes away

but that feels a bit less definitive

(the tl;dr is that in the right circumstances, regular I/O to a given LBA can jump in front of a TRIM zio in the queue that overlaps with the i/o)

so instead of TRIM then write, you end up writing then TRIM

which of course is not good

the tricky part is because of the multi-threaded and asynchronous nature of all of that, actually catching that in the act

(this also appears to be present in openzfs as well)

jbk: perhaps experiment with dtrace's chill() to insert delays which increase the likelihood of the race going the way you want?

(but if it's all asynch code that might not help that much..)

the problem is i'm not sure this is all going to happen on the same thread

[illumos-gate] 15839 Erroneous newline in error message -- Jorge Fabregat Lopez <jfabregat⊙pc>

[illumos-gate] 15780 audio: void operator delete(void*)' called -- Toomas Soome <tsoome⊙mc>

[illumos-gate] 15760 dhcpagent: the comparison will always evaluate as 'false' -- Toomas Soome <tsoome⊙mc>

i've put some more details in the ticket that hopefully explains more details

Hey all, for Zig support is there any preference over whether it prefers to use `/usr/lib` vs. `/lib`? Also what about `64` vs. `amd64`?

I don't think you should be hardcoding amd64 unless it's in an amd64 specific area. I would probably use 64 as that'll be present on all archs I think (including 64-bit only richlowe?).

Yes, 64 is present on aarch64 as a symlink to .

For /lib and /usr/lib, the search order is usually that - /lib/64:/usr/lib/64

that's helpful, thanks

but it can be customised on a system with `crle(1)` of course

.../64 is generic, and the one to use

on multi-arch platforms it's a symlink to `$(MACH64)`, on 64-bit only it's a symlink to `.`

so if you're trying to be generic, it will do the right thing for you

<Jeopardy> I'll take unusual corner-cases for $300, Ken. </Jeopardy>

Don't let the corner-case turn you into a basket-case.

I need to edit a bunch of IPDs about this stuff, but I'm not sure how best to go about it, and it hasn't been pressing yet

I think at present everything is in the AArch64 one

but gdamore stream-of-consciousnessed a bunch of random stuff into 2 related ones, that need a firm editting to match

or superceding? I dunno, that's why I haven't :)

should boot loader modules work for replacing a driver, or does that only work for files like /etc/system and such?

mesonbuild/meson #12320 - apparently x86 OS'es where you can't use int 0x80 with Linux syscall ids are rare corner cases now

I think it should work, but I have never done it, if you mean bootfs

I think so too - I've seen it used to replace dtrace.conf, so presumably it could also replace a driver.

Wow @alanc, and thanks.

My corner case is smatch-on-SmartOS is whining about somethign smatch-on-gate isn't. Only diffs are in *makefiles* between our smatch and -gates.

The most important thing, based on your mail, is whether your smatch is _correct_

definitely don't write it off as smartos weirdness if it really is broken code

It's not broken code. if I invoke smatch directly it hits errors in subsequent pieces where

the "freed buffer" isn't.

Go look at the code and chase its functions down. I don't see code errors. Happy to be told I missed something, TBH, but I don't see it.

"dec_ctx" is only freed by smb_dr_decode_finish() and not a moment earlier.

hrm... loader says it loaded the file, but then it doesn't show up under /system/boot

danmcd: without a broken smatch I have exactly one guess, and it would take a little dtrace from you. Is there any possibility one system is using the "check_free" checker, where one is using the "check_free_strict" checker?

the "strict" one contains comments like "It makes it easier to consider NULL pointers as freed"

but the way the checkers are intertwined, and don't name themselves, makes it hard to reason about.

but everything about your fix seems like it should have worked, so I'm ignoring that to try to work out why the behavious is different at all.

if that makes sense

I say "dtrace" you could just make the messages they emit distinct if you wanted :)

I think both -gate's and -joyent's hit check_free_strict(). I need to remember how to make a process stop at launch...

i don't think that made it out before the barn door closed

I remember.

truss is your friend there.

Problem is... both hit check_free_strict() but both return from it immediately because KERNEL isn't set.

ahh..

danmcd: it's been a while but pretty sure I usually reached for `truss -U` there

Reaching it is one thing. FIRST THING the function does is check for "project ==/!= KERNEL" and returns appropriately.

maybe that's also a hint on how to implement the functionality (though I can't recall the command now.. i thought it was maybe a flag to prun, but doesn't look like it)

No difference in patching either. (Had to check that.) Same diffs as with before-this-fix.

And I gotta go. Sorry (esp @tsoome ).

no worries, it is interesting how it did pop up, however