07:47:41 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. 07:47:58 I'm glad it seems to be a general upstream problem though! 16:01:06 anyone have any ideas on tracking stuff w/ dtrace across the zio pipeline and scheduler? 16:02:11 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 16:02:43 looking at the trim code, i've found a pretty sensible explanation, and with the obvious fix, the corruption goes away 16:03:12 but that feels a bit less definitive 16:04:31 (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) 16:04:44 so instead of TRIM then write, you end up writing then TRIM 16:04:51 which of course is not good 16:05:57 the tricky part is because of the multi-threaded and asynchronous nature of all of that, actually catching that in the act 16:06:55 (this also appears to be present in openzfs as well) 17:03:50 jbk: perhaps experiment with dtrace's chill() to insert delays which increase the likelihood of the race going the way you want? 17:04:21 (but if it's all asynch code that might not help that much..) 17:05:05 the problem is i'm not sure this is all going to happen on the same thread 17:41:15 [illumos-gate] 15839 Erroneous newline in error message -- Jorge Fabregat Lopez 18:00:04 [illumos-gate] 15780 audio: void operator delete(void*)' called -- Toomas Soome 18:24:30 [illumos-gate] 15760 dhcpagent: the comparison will always evaluate as 'false' -- Toomas Soome 19:47:08 i've put some more details in the ticket that hopefully explains more details 20:32:31 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`? 20:34:41 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?). 20:35:19 Yes, 64 is present on aarch64 as a symlink to . 20:36:24 For /lib and /usr/lib, the search order is usually that - /lib/64:/usr/lib/64 20:37:36 that's helpful, thanks 20:37:42 but it can be customised on a system with `crle(1)` of course 20:44:03 .../64 is generic, and the one to use 20:44:31 on multi-arch platforms it's a symlink to `$(MACH64)`, on 64-bit only it's a symlink to `.` 20:44:56 so if you're trying to be generic, it will do the right thing for you 20:46:04 I'll take unusual corner-cases for $300, Ken. 20:46:58 Don't let the corner-case turn you into a basket-case. 20:48:24 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 20:48:32 I think at present everything is in the AArch64 one 20:48:58 but gdamore stream-of-consciousnessed a bunch of random stuff into 2 related ones, that need a firm editting to match 20:49:31 or superceding? I dunno, that's why I haven't :) 20:57:10 should boot loader modules work for replacing a driver, or does that only work for files like /etc/system and such? 20:57:38 https://github.com/mesonbuild/meson/pull/12320 - apparently x86 OS'es where you can't use int 0x80 with Linux syscall ids are rare corner cases now 20:57:40 I think it should work, but I have never done it, if you mean bootfs 20:58:23 I think so too - I've seen it used to replace dtrace.conf, so presumably it could also replace a driver. 21:07:29 Wow @alanc, and thanks. 21:08:39 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. 21:15:00 The most important thing, based on your mail, is whether your smatch is _correct_ 21:15:50 definitely don't write it off as smartos weirdness if it really is broken code 21:20:23 It's not broken code. if I invoke smatch directly it hits errors in subsequent pieces where 21:21:21 the "freed buffer" isn't. 21:21:56 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. 21:26:54 "dec_ctx" is only freed by smb_dr_decode_finish() and not a moment earlier. 21:27:34 hrm... loader says it loaded the file, but then it doesn't show up under /system/boot 21:31:41 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? 21:33:18 the "strict" one contains comments like "It makes it easier to consider NULL pointers as freed" 21:34:04 but the way the checkers are intertwined, and don't name themselves, makes it hard to reason about. 21:35:33 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. 21:35:39 if that makes sense 21:36:01 I say "dtrace" you could just make the messages they emit distinct if you wanted :) 21:51:50 I think both -gate's and -joyent's hit check_free_strict(). I need to remember how to make a process stop at launch... 21:52:33 i don't think that made it out before the barn door closed 21:58:15 I remember. 21:58:21 truss is your friend there. 21:58:37 Problem is... both hit check_free_strict() but both return from it immediately because KERNEL isn't set. 21:58:55 ahh.. 22:00:22 danmcd: it's been a while but pretty sure I usually reached for `truss -U` there 22:00:49 Reaching it is one thing. FIRST THING the function does is check for "project ==/!= KERNEL" and returns appropriately. 22:00:52 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) 22:09:46 No difference in patching either. (Had to check that.) Same diffs as with before-this-fix. 22:10:03 And I gotta go. Sorry (esp @tsoome ). 22:10:37 no worries, it is interesting how it did pop up, however