02:48:01 some distros are still doing shadow builds with gcc7, right? 02:55:51 (this seems too easy, so something can't be right :P) 03:05:57 We still require gcc7 shadow. 03:08:05 ok.. that's what I thought.. 03:45:04 i'm experimenting with -ffile-prefix-map and I think I might have it working with all of usr/src/uts already (so that all of the paths are resolved relative to $SRC) 03:50:00 e.g. an ASSERT() or VERIFY() (or the dward debug file info) would show 'usr/src/uts/common/io/vioif/vioif.c' for the path instead of '../../common/io/vioif/vioif.c' 06:58:28 jbk That's nice! 12:46:20 https://github.com/jasonbking/illumos-gate/tree/path has what I have so far (obviously very much a work in progress right now) 12:54:04 but it seems like it's working for all the kernel stuff (at least checking genunix and spot checking a couple of modules.. not sure of an easy way to check all the modules w/o generating a lot of extra noise) 13:12:09 libs and cmds i think won't be quite as easy 13:12:18 well not that it'll be hard, just tedious 13:39:48 also don't know if a different approach might not be better 13:40:09 this was something i just came up with in an evening a few years ago, but had to shelve it since it didn't work with gcc7 13:40:21 but now is more useful 13:40:27 at least potentially 14:39:52 Just the three commits in your `path` branch? 14:54:31 yeah 14:54:58 it just does the kernel stuff right now (+ libdemangle-sys since it's still just kinda figuring things out) 14:56:30 if we ever get to source level debugging nirvana w/ mdb :P i don't know if that would help as well since that should also make the paths for the DWARF source info appear the same way 14:56:48 or I guess i don't know for sure if it'd help, but seems like it might 14:57:26 since it'd mean they're always recorded based off the root of the source tree 14:59:37 it adds a new build tool (it handles resolving relative paths), so you need to build and use usr/src/tools 15:00:16 (also something that might need to be addressed either as a flag day or such IF it's something eventually worth integrating, and a better approach isn't found) 15:03:48 Having consistent source paths there definitely helps with mdb and dwarf. It was something I wanted for my ::source prototype. 15:04:11 You already need to use the bundled tools most of the time anyways because of ld. 15:04:44 Though I think we should figure out if we can't figure out a way to be clever with make variables versus yet another fork/exec, but getting it to the point where that's our problem will be great. 15:13:31 yeah, i figured that would be the next step (if possible) after making sure it worked :) 15:15:06 the utility currently also hard codes the use CODEMGR_WS which probably could be done better 17:30:31 [illumos-gate] 15578 pxeboot: bugs in pxe.h -- Toomas Soome 17:37:49 [illumos-gate] 15564 Idmapd can contact old servers after changing DC or GC -- Matt Barden 18:41:02 [illumos-gate] 15581 libvmmapi finds headers outside proto area -- Patrick Mooney 21:13:46 It's been a while since I've looked at UMEM_DEBUG options beyond, "default", but I *thought* doing: 21:16:30 waiting with baited breath here 21:17:02 it's almost certain what you're asking is in umem_debug(3malloc) 21:17:04 Dammmit. 21:17:05 if that helps in the meantime 21:17:05 Typo. 21:17:21 `mtbf` is not spelled `mbtf`. 21:17:26 ah, yes. 21:18:55 What I REALLY want is a specific malloc to fail. 21:19:08 So do you want to do it programatically? 21:19:10 put a breakpoint on it and force it to return? 21:19:26 Because clearly these usr/src/test programs aren't designed to be resilient here. 21:19:29 In tests, you can call into umem to change the failure rate. 21:19:43 on my sloppy favourite: let it return and then write 0 into %rax 21:19:53 I've already done breakpoint-and-zero-out-rax. I'd like a single specific malloc 21:19:54 for tests, I think as robert says you can bump the failure rate to 100% for that one call? 21:20:02 I will get an example. 21:20:03 to fail both before and after. 21:20:18 So ultimately how intrusive do you want to be? 21:20:29 That is, you can do with DTrace, mdb, or by modifying the program. 21:21:41 I already know how to do mdb. I *WANT* to give something that can be invoked with 1-2 commands, where one is the program (/opt/crypto-tests/tests/aes/kcf/aes_gcm_*) 21:21:59 Are you willing to rebuild a component or not? 21:22:35 https://www.illumos.org/issues/12359 and umem_setmtbf allows you to set it at run time. This is used in the memory streams tests. 21:22:36 → FEATURE 12359: Want a means to set the umem mtbf at runtine (Closed) 21:22:46 Otherwise, you are going to want to use the pid provider and writable uregs. 21:23:18 Yeah... as we have this conversation, I think this might be an additional teaching opportunity for mdb and by-instruction goodness. 21:23:30 There is no CLI based way to dynamically change this. I guess maybe you could set umem_debug and then use the pid provider to change the mtbf. 21:23:59 (this is for one of our younger employees at MNX, he wanted a bite-sized and I pointed him at fenix illumos#13470) 21:24:00 BUG 13470: potential crash in in gcm decrypt_update if kmem_alloc fails (New) 21:24:00 ↳ https://www.illumos.org/issues/13470 21:24:11 Fix is simple AF. Testing is the hard (ish) part. 21:26:21 If you're trying to test the kernel bit, I would use kmdb. 21:26:25 And just change rax. 21:26:42 That is the shortest path to success here imho. 21:26:55 Harder to exercise the kernel bit proper, so the test program from usr/src/test is the next best thing. 21:27:57 Right, you just run that in kcf mode, set a breakpoint in the kernel and then step through it and change rax? 21:28:35 Yep. Which I did already myself to reproduce the bug. I'm going to have to step Nolan through it. 21:29:13 There is also https://www.illumos.org/books/mdb which has some small bits that may help for them. 21:31:42 Oooh good idea about the books. 22:53:02 just to ask, ISTR it being the case for mr_sas, but is mpt_sas also known to lose track of struct bufs during a reset? 22:55:22 i got a dump from someone (on omnios 151038) w/ a dead drive, and it doesn't seem like mpt_sas is actually timing out the scsi mode sense sent during sdattach