User Details
- User Since
- Jan 29 2016, 5:27 AM (424 w, 3 d)
Feb 13 2024
@glebius dully noted. ๐๐ง
Feb 9 2024
Feb 8 2024
Looks like I'm able to turn INVARIANTS just in that specific TU, let's see if we deploy it into production and narrow it down:
Crash trace seems to be misleading, based on the crash IP (0xffffffff80664190), the crash is inside m_apply():
Dump of assembler code for function m_apply: 0xffffffff80664100 <+0>: push %rbp 0xffffffff80664101 <+1>: mov %rsp,%rbp 0xffffffff80664104 <+4>: push %r15 0xffffffff80664106 <+6>: push %r14 0xffffffff80664108 <+8>: push %r13 0xffffffff8066410a <+10>: push %r12 0xffffffff8066410c <+12>: push %rbx 0xffffffff8066410d <+13>: sub $0x18,%rsp 0xffffffff80664111 <+17>: mov %r8,-0x38(%rbp) 0xffffffff80664115 <+21>: mov %rcx,-0x30(%rbp) 0xffffffff80664119 <+25>: mov %edx,%r12d 0xffffffff8066411c <+28>: mov %rdi,%rbx 0xffffffff8066411f <+31>: test %esi,%esi 0xffffffff80664121 <+33>: jle 0xffffffff80664140 <m_apply+64> 0xffffffff80664123 <+35>: mov %esi,%eax 0xffffffff80664125 <+37>: cs nopw 0x0(%rax,%rax,1) 0xffffffff8066412f <+47>: nop 0xffffffff80664130 <+48>: sub 0x18(%rbx),%eax 0xffffffff80664133 <+51>: jl 0xffffffff80664149 <m_apply+73> 0xffffffff80664135 <+53>: mov (%rbx),%rbx 0xffffffff80664138 <+56>: mov %eax,%esi 0xffffffff8066413a <+58>: test %eax,%eax 0xffffffff8066413c <+60>: jg 0xffffffff80664130 <m_apply+48> 0xffffffff8066413e <+62>: jmp 0xffffffff80664142 <m_apply+66> 0xffffffff80664140 <+64>: mov %esi,%eax 0xffffffff80664142 <+66>: test %r12d,%r12d 0xffffffff80664145 <+69>: jg 0xffffffff80664190 <m_apply+144> 0xffffffff80664147 <+71>: jmp 0xffffffff80664150 <m_apply+80> 0xffffffff80664149 <+73>: mov %esi,%eax 0xffffffff8066414b <+75>: test %r12d,%r12d 0xffffffff8066414e <+78>: jg 0xffffffff80664190 <m_apply+144> 0xffffffff80664150 <+80>: xor %eax,%eax 0xffffffff80664152 <+82>: add $0x18,%rsp 0xffffffff80664156 <+86>: pop %rbx 0xffffffff80664157 <+87>: pop %r12 0xffffffff80664159 <+89>: pop %r13 0xffffffff8066415b <+91>: pop %r14 0xffffffff8066415d <+93>: pop %r15 0xffffffff8066415f <+95>: pop %rbp 0xffffffff80664160 <+96>: ret 0xffffffff80664161 <+97>: cs nopw 0x0(%rax,%rax,1) 0xffffffff8066416b <+107>: nopl 0x0(%rax,%rax,1) 0xffffffff80664170 <+112>: cltq 0xffffffff80664172 <+114>: add %rax,%rsi 0xffffffff80664175 <+117>: mov -0x38(%rbp),%rdi 0xffffffff80664179 <+121>: mov %r14d,%edx 0xffffffff8066417c <+124>: call *-0x30(%rbp) 0xffffffff8066417f <+127>: test %eax,%eax 0xffffffff80664181 <+129>: jne 0xffffffff80664152 <m_apply+82> 0xffffffff80664183 <+131>: sub %r14d,%r12d 0xffffffff80664186 <+134>: mov (%rbx),%rbx 0xffffffff80664189 <+137>: xor %eax,%eax 0xffffffff8066418b <+139>: test %r12d,%r12d 0xffffffff8066418e <+142>: jle 0xffffffff80664152 <m_apply+82> 0xffffffff80664190 <+144>: mov 0x18(%rbx),%r14d ^^^^^^^^^^^^^^ End of assembler dump.
Different calls chain though, @markj any ideas? ๐
Looks like some other issue at play, I am seeing those crashes even with my patch applied.
Feb 7 2024
o sorted alphabetically;
o updated .Dd.
Jan 22 2024
P.S. popen(3) under the hood uses /bin/sh, so it needs tons of stuff to be present and working. Not to mention having fstat around is not guranteed.
Looks OKish (I never used that feature myself, only for testing), but the fact that this is now runs by default and tries to do bunch of unnecessary magic under the hood is of a big concern. I already have a problem with pkg starting to open /dev/null just in case, I don't want this to cause my builds to start suddenly failing right and left.
Dec 5 2023
May 10 2023
Dec 26 2022
Sep 13 2022
Sep 8 2022
termcap.small is still useful I think for the case when /usr is not mounted (i.e. single-user/recovery mode in a traditional FS layout). These days of course most people are using monolithic root+usr esp with ZFS, however we for example have 200+ systems in the field partitioned in a traditional way, so I am wondering how many there may be people like us out there.