I managed to get libc with debugging symbols built after putting SOURCEDEBUG=yes in the right place, but that's not all the way to a debuggable state.

Skipping optimizations seems like a needed step. Also rebuilding C++ libraries, for which I am a bit more lost. Is core C++ part of illumos-gate?

My stackstrace is at the bottom of netizen.se/docs/urxvt-out_of_input in case anyone would happen to have a set of very helpful spare eyes.

|cos| what seems to be the problem there?

tsoome_: urxvt crashes, within minutes of normal use. i'm hoping to figure out why.

yes, that much I figured:)

but from that stack trace? if you are getting __cxa_throw from cmd_getc, it should be traceable from the source?

it is highly possible that my approach is all wrong. my assumption is that it'll be a challenge for me to figure out this bug even with debug symbols, but that i might have a chance with them.

the thing making it tricky to simply step the code is that there is a signal boundary to cross, but i guess discussing that would be way too verbose for this channel.

[illumos-gate] 17414 bhyve could iterate over GPTs better -- Patrick Mooney <pmooney⊙pc>

ya. bad thing is that tar download does not seem to happen atm:)

[illumos-gate] 17405 clarify tools usage in nightly(1) -- Patrick Mooney <pmooney⊙pc>

gotta love Intel putting out a security bulletin that literally says "A subset of affected processors may need to apply additional software mitigations, details of which can be found at the Linux* kernel Github* link in the Related Content section." where the link is simply to the top level of the Linux git repo, suggesting the fix is simply to adopt the Linux kernel in its entirety

alanc: lol

just guess which of the 1,352,981 commits in that repo apply to this issue, what are the odds?

any chance the CVE might be in the relevant commit msg?

just don't branch, imo

The CVE id appears in one of the documentation files, but I don't see it in the commit history

and the documentation was a separate commit from the fix: torvalds/linux 1ac116c

→ GitHub commit 1ac116c: Documentation: x86/bugs/its: Add ITS documentation (committed)

pretend I made a pdp-10 joke

alanc: perhaps torvalds/linux f481888 ??

seems a reasonable thought

I was going to say look at commits around (before?) the doc one, that have a wrmsr in

(I took the max power approach and looked for the files that referenced the tunable and then did a git blame)

which this wouldn't have found, because this looks to be super stupid

danmcd: I assume this is why you're updating ucode?

danmcd: so maybe you're interested in this goose too

Interesting... Xen leaked a day early too.

this is the one they told us last week was going to be released on Monday, ahead of the normal Patch Tuesday batch tomorrow

presumably because vusec.net/projects/training-solo is being presented at sp2025.ieee-security.org which starts today so may be available to attendees in the proceedings

or actually, to anyone with IEEE library access now: computer.org/csdl/proceedings/sp/2025/21B7ONGXzZ6

alanc: sounds right.

Oh BTW alanc esp => Xen may have leaked it early.

See the oss-security alias.

do any of you who know ID mapping, know of anything that would happen when the idmap service is restarted that does not happen when it is started?

or whether idmap changes its behaviour based on services or facilities that are available when it starts

the bug I'm chasing turns out to go away entirely if, after idmap is started, I restart it

which is unfortunate both in amount of time I've wasted, and amount of time I have to waste to get it broken

restart or refresh?

(doesn't the former stop/start, while the latter HUPs?)

also what behavior are you seeing specifically?

specifically restart, refresh didn't (though I did not change a property, and also refresh)

the behaviour is that the `findroot` test sommerfeld added fails, because the first SID vanishes from idmap's knowledge almost immediately

it can be condensed to `; /usr/bin/find . -sidacl S-1-5-21-44444444-55555555-66666666 && idmap dump -v && /usr/bin/find . -sidacl S-1-5-21-11111111-22222222-33333333 && idmap dump -v`

(you should pick an empty directory, or the find will take ages for no reason)

it works on x86, I should add

on arm, if idmap has not been restarted, the first SID vanishes from the 2nd dump

if it has been restarted, it's fine

I have not yet checked if it has been disabled/enabled, rather than restarted

because this is all a bit time consuming, now I know it has to be fully reset each time to test it

(this also means enabling the debugging is unfortunate, in as much as the act of doing so means it will now work)

disable && sleep 5 && enable is equivalent to 'restart'ing, result wise

richlowe: I recall you mentioning something like this a while back. some sort of machine-dependent quirk? hidden dependence on memory ordering?

I'm still trying to track down in what situations it works and doesn't. 'refresh' is not sufficient, even with a property change.

but immediately after reboot, is broken, it doesn't have to be a _clean_ image

tomorrow, it's truth table time just so I don't forget.

another one for IPD 14: github.com/illumos/illumos-gate/blo…usr/src/uts/common/sys/strlog.h#L55

I'm not deeply familiar with the idmap code and it's got enough asynchrony to it that it's a pain to understand what it's going.

what it's doing or where it's going. take your pick..

ephemeral mappings are stored in an sqlite (not sqlite3) database in /var/run/idmap/cache.db

so it could be an sqlite bug

long since fixed in sqlite3

so in terms of "how is the first start different from subsequent starts", the first one since reboot creates cache.db; later ones reuse it.

so one informative experiment would be to convert idmapd to sqlite3 and see if the problem goes away.

and, well, if it doesn't fix it on arm we've at least upgraded it to sqlite3

actually, I think there's some locking missing in idmapd around ephemeral id allocation.

allocation happens in `get_next_eph_uid`, called from `dynamic_ephemeral_mapping` and walking up the call stack I don't see anything taking a write lock.

(unless rpc-over-doors single-threads the server..)