some distros are still doing shadow builds with gcc7, right?

(this seems too easy, so something can't be right :P)

We still require gcc7 shadow.

ok.. that's what I thought..

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)

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'

jbk That's nice!

github.com/jasonbking/illumos-gate/tree/path has what I have so far (obviously very much a work in progress right now)

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)

libs and cmds i think won't be quite as easy

well not that it'll be hard, just tedious

also don't know if a different approach might not be better

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

but now is more useful

at least potentially

Just the three commits in your `path` branch?

yeah

it just does the kernel stuff right now (+ libdemangle-sys since it's still just kinda figuring things out)

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

or I guess i don't know for sure if it'd help, but seems like it might

since it'd mean they're always recorded based off the root of the source tree

it adds a new build tool (it handles resolving relative paths), so you need to build and use usr/src/tools

(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)

Having consistent source paths there definitely helps with mdb and dwarf. It was something I wanted for my ::source prototype.

You already need to use the bundled tools most of the time anyways because of ld.

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.

yeah, i figured that would be the next step (if possible) after making sure it worked :)

the utility currently also hard codes the use CODEMGR_WS which probably could be done better

[illumos-gate] 15578 pxeboot: bugs in pxe.h -- Toomas Soome <tsoome⊙mc>

[illumos-gate] 15564 Idmapd can contact old servers after changing DC or GC -- Matt Barden <mbarden⊙rc>

[illumos-gate] 15581 libvmmapi finds headers outside proto area -- Patrick Mooney <pmooney⊙pc>

It's been a while since I've looked at UMEM_DEBUG options beyond, "default", but I *thought* doing:

waiting with baited breath here

it's almost certain what you're asking is in umem_debug(3malloc)

Dammmit.

if that helps in the meantime

Typo.

`mtbf` is not spelled `mbtf`.

ah, yes.

What I REALLY want is a specific malloc to fail.

So do you want to do it programatically?

put a breakpoint on it and force it to return?

Because clearly these usr/src/test programs aren't designed to be resilient here.

In tests, you can call into umem to change the failure rate.

on my sloppy favourite: let it return and then write 0 into %rax

I've already done breakpoint-and-zero-out-rax. I'd like a single specific malloc

for tests, I think as robert says you can bump the failure rate to 100% for that one call?

I will get an example.

to fail both before and after.

So ultimately how intrusive do you want to be?

That is, you can do with DTrace, mdb, or by modifying the program.

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_*)

Are you willing to rebuild a component or not?

illumos.org/issues/12359 and umem_setmtbf allows you to set it at run time. This is used in the memory streams tests.

→ FEATURE 12359: Want a means to set the umem mtbf at runtine (Closed)

Otherwise, you are going to want to use the pid provider and writable uregs.

Yeah... as we have this conversation, I think this might be an additional teaching opportunity for mdb and by-instruction goodness.

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.

(this is for one of our younger employees at MNX, he wanted a bite-sized and I pointed him at fenix illumos#13470)

BUG 13470: potential crash in in gcm decrypt_update if kmem_alloc fails (New)

↳ illumos.org/issues/13470

Fix is simple AF. Testing is the hard (ish) part.

If you're trying to test the kernel bit, I would use kmdb.

And just change rax.

That is the shortest path to success here imho.

Harder to exercise the kernel bit proper, so the test program from usr/src/test is the next best thing.

Right, you just run that in kcf mode, set a breakpoint in the kernel and then step through it and change rax?

Yep. Which I did already myself to reproduce the bug. I'm going to have to step Nolan through it.

There is also illumos.org/books/mdb which has some small bits that may help for them.

Oooh good idea about the books.

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?

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