`shift $#' inside for loop without `in word...' part alters the loop's copy of positional parameters

2021-10-20 Thread Oğuz 
To reproduce, put this into a file (say `foo'),

for x; do
  shift $#
  echo $x
done

and run

$ sh ./foo x y z
x
y
./foo

The last line should be `z', obviously, but it's not.


-- 
Oğuz

[Firefox] Tab crashes when loading some sites on 93.0 [OpenBSD 7.0]

2021-10-20 Thread bug . igjym 
This wasn't the case on OpenBSD 6.9 with older version of Firefox (although FF 
on 6.9 had other issues, like slow tab switching, which is still present in 
tor-browser-10.5.5 but is fixed in FF 93). When I installed Firefox 93 and did 
customizations, installed addons, I tried to load odysee.com. After a while the 
tab crashed with a "Gah. Your tab just crashed." screen.

Thinking that it was an issue with some of the about:config settings I changed, 
or some addon I installed, I tried Menu - Help - Troubleshoot mode. To my 
surprise, tab crashed even on troubleshooting mode. (Screenshot attached, which 
shows that I'm in troubleshooting mode when tab crashed) I tried to refresh 
Firefox after renaming my ~/.mozilla/firefox to let it create a new profile - 
but it didn't help. Tried increasing ulimit from login.conf from 512 to 2048, 
didn't help either. So the problem should be somewhere else, not my changes or 
addons.

 says to 
disable webgl (change webgl.disabled to true on about:config) but it didn't 
help.

One thing I noticed is that first time I tried odysee.com, it used to crash on 
JS loading animation thingy that the page shows. When I kept trying to load it 
again and again, it gradually delayed the crash every time. e.g. loading the 
thumbnails and then crash... next time loading some more thumbnails and then 
crash... next time loading all the thumbnails but when login page is visited 
then crashed and so on. This timing resets after rebooting the system 
(restarting FF doesn't reset the crash time for some reason). This initially 
got me suspect if it was due to something system related, not Firefox. So I 
tried with ulimit, but as I've mentioned, increasing it didn't help.

Sometimes if I have other tabs open which work fine without issues other times, 
starts to crash when odysee.com tab crashes. For example I can have a Searx tab 
open and it works ok all day long, but when odysee.com tab crashes, the Searx 
tab also crashes. It doesn't happen always but sometimes.

One thing I do need to note that this crash is not limited to odysee.com only. 
Other sites that cause tab crash include:
- https://mail.tutanota.com
- https://mail.protonmail.com
- https://news.itsfoss.com/
- and gitlab.com sign in page https://gitlab.com/users/sign_in (doesn't crash 
on the homepage, only login page).

These URLs load fine on Iridium just fine.

I ran pkg_add -Uu before submitting this report and the issue is still there.

Another issue I don't know if it's related is that my password manager addon 
doesn't work in FF 93 on OBSD. It can show it's popup menu, but can't list the 
site's password(s). It works fine on Iridium 2021.06.91 on OBSD and Librewolf 
on GNU+Linux.

This is on a fresh new install of OpenBSD 7.0 just done some days ago after it 
was released. It is inside encrypted (softraidfde) on a 32gb USB flash drive, 
with 2gb swap and around 27gb for /. The machine is ThinkPad x201i with i3 CPU 
with 4gb of RAM.

## Steps to reproduce:

1. Start Firefox
2. Visit https://odysee.com
3. Wait for a few seconds

## Current result:

Shows a "Gah. Your tab just crashed." error page after a while.

If it doesn't crash for some reason, go to sign in page and try to sign in and 
it crashes for sure.

## Expected outcome:

Load the page without errors showing and don't crash the tab

OpenBSD 7.0 (GENERIC.MP) #232: Thu Sep 30 14:25:29 MDT 2021
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4062691328 (3874MB)
avail mem = 3923525632 (3741MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xe0010 (78 entries)
bios0: vendor LENOVO version "6QET70WW (1.40 )" date 10/11/2012
bios0: LENOVO 3323K2M
acpi0 at bios0: ACPI 4.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET ASF! SLIC BOOT SSDT TCPA SSDT 
SSDT SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP1(S4) EXP2(S4) EXP3(S4) 
EXP4(S4) EXP5(S4) EHC1(S3) EHC2(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i3 CPU M 330 @ 2.13GHz, 2128.33 MHz, 06-25-02
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 132MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i3 CPU M 330 @ 2.13GHz, 2128.01 MHz, 06-25-02
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,

Re: riscv64 panic

2021-10-20 Thread Jeremie Courreges-Anglas 
On Wed, Oct 20 2021, Jeremie Courreges-Anglas  wrote:
> On Fri, Oct 08 2021, Mark Kettenis  wrote:
>>> From: Jeremie Courreges-Anglas 
>>> Date: Fri, 08 Oct 2021 18:19:47 +0200
>>> 
>>> riscv64.ports was running dpb(1) with two other members in the build
>>> cluster.  A few minutes ago I found it in ddb(4).  The report is short,
>>> sadly, as the machine doesn't return from the 'bt' command.
>>> 
>>> The machine is acting both as an NFS server and and NFS client.
>>> 
>>> OpenBSD/riscv64 (riscv64.ports.openbsd.org) (console)
>>> 
>>> login: panic: pool_anic:t: pol_ free l: p mod fiee liat m  oxifief:c a2e 
>>> 07ff0ff fte21ade0 00f ifem c0d
>>> 1 07f1f0ffcf2177 010=0 c16ce6 7x090xc52c !
>>> 0x9066d21 919 xc1521
>>> Stopped at  panic+0xfe: addia0,zero,256TIDPIDUID
>>>  PR
>>> FLAGS PFLAGS  CPU  COMMAND
>>>   24243  43192 55 0x2  00  cc
>>> *480349  52543  00x11  01  perl
>>>  480803  72746 55 0x2  03  c++
>>>  366351   3003 55 0x2  02K c++
>>> panic() at panic+0xfa
>>> panic() at pool_do_get+0x29a
>>> pool_do_get() at pool_get+0x76
>>> pool_get() at pmap_enter+0x128
>>> pmap_enter() at uvm_fault_upper+0x1c2
>>> uvm_fault_upper() at uvm_fault+0xb2
>>> uvm_fault() at do_trap_user+0x120
>>> https://www.openbsd.org/ddb.html describes the minimum info required in bug
>>> reports.  Insufficient info makes it difficult to find and fix bugs.
>>> ddb{1}> bt
>>> panic() at panic+0xfa
>>> panic() at pool_do_get+0x29a
>>> pool_do_get() at pool_get+0x76
>>> pool_get() at pmap_enter+0x128
>>> pmap_enter() at uvm_fault_upper+0x1c2
>>> uvm_fault_upper() at uvm_fault+0xb2
>>> uvm_fault() at do_trap_user+0x120
>>> do_trap_user() at cpu_exception_handler_user+0x7a
>>> 
>>> 
>>> The conserver logs for this console provide a hint about when it
>>> happened:
>>> 
>>> --8<--
>>> [-- MARK -- Fri Oct  8 08:00:00 2021]
>>> [-- MARK -- Fri Oct  8 09:00:00 2021]
>>> [-- MARK -- Fri Oct  8 10:00:00 2021]
>>> bt
>>> ^Mpanic() at panic+0xfa
>>> ^Mpanic() at pool_do_get+0x29a
>>> ...
>>> -->8--
>>> 
>>> It seems that Theo was plugging/unplugging usb cables at that time.
>>> I asked Theo to reboot the machine as I couldn't get more useful output.
>>
>> Thanks for the heads up.  Some sort of memory corruption, but no real
>> clues what caused it.
>
> Another one, maybe a similar cause, maybe not. :-/
>
> [...]
> OpenBSD 7.0-current (GENERIC.MP) #84: Mon Oct 18 01:23:24 MDT 2021
> dera...@riscv64.openbsd.org:/usr/src/sys/arch/riscv64/compile/GENERIC.MP
> [...]
> OpenBSD/riscv64 (riscv64.ports.openbsd.org) (console)
>
> login: t[0] == 0x
> t[1] == 0xffc00034feb2
> t[2] == 0xffc227cd9630
> t[3] == 0xffc0008cf1b0
> t[4] == 0x0022
> t[5] == 0x
> t[6] == 0x7c9bd777
> s[0] == 0xffc227cd9680
> s[1] == 0xffc2229d8d28
> s[2] == 0xffc000a5e9a8
> s[3] == 0xffc2229ad6a0
> s[4] == 0xffc0008ff1f8
> s[5] == 0x
> s[6] == 0xffc22a21a050
> s[7] == 0x
> s[8] == 0xffc000a20d30
> s[9] == 0xffc000a25718
> s[10] == 0xffc000a8f6a0
> s[11] == 0xffc000a25714
> a[0] == 0x95b8040228044314
> a[1] == 0x95b8040228044314
> a[2] == 0xffc2229d8d28
> a[3] == 0x0001
> a[4] == 0xffc023027800
> a[5] == 0x
> a[6] == 0x0003
> a[7] == 0xffc0008cf1a0
> sepc == 0xffc0002f043e
> sstatus == 0x00020120
> stval == 0xff822804431c
> scause == 0x000d
> panic: Fatal page fault at 0xffc0002f043e: 0xff822804431c
> Stopped at  panic+0xfe: addia0,zero,256TIDPIDUID 
> PR
> FLAGS PFLAGS  CPU  COMMAND
>  469890  40238 550x12  02  sh
> *380568  80457 550x12  03K touch
>  299235  73888 55 0x2  01  perl
>   15710  89701 560x12  00  ftp
> panic() at panic+0xfa
> panic() at do_trap_supervisor+0x232
> dump_regs() at cpu_exception_handler_supervisor+0x78
> cpu_exception_handler_supervisor() at pool_put+0x30
> pool_put() at ffs_reclaim+0x5c
> ffs_reclaim() at VOP_RECLAIM+0x32
> VOP_RECLAIM() at vclean+0x122
> https://www.openbsd.org/ddb.html describes the minimum info required in bug
> reports.  Insufficient info makes it difficult to find and fix bugs.
> ddb{3}>

The machine is waiting in ddb(4).  In the past panics, I didn't get
control back after typing a ddb command, better choose wisely. ;)

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: riscv64 panic

2021-10-20 Thread Jeremie Courreges-Anglas 
On Fri, Oct 08 2021, Mark Kettenis  wrote:
>> From: Jeremie Courreges-Anglas 
>> Date: Fri, 08 Oct 2021 18:19:47 +0200
>> 
>> riscv64.ports was running dpb(1) with two other members in the build
>> cluster.  A few minutes ago I found it in ddb(4).  The report is short,
>> sadly, as the machine doesn't return from the 'bt' command.
>> 
>> The machine is acting both as an NFS server and and NFS client.
>> 
>> OpenBSD/riscv64 (riscv64.ports.openbsd.org) (console)
>> 
>> login: panic: pool_anic:t: pol_ free l: p mod fiee liat m  oxifief:c a2e 
>> 07ff0ff fte21ade0 00f ifem c0d
>> 1 07f1f0ffcf2177 010=0 c16ce6 7x090xc52c !
>> 0x9066d21 919 xc1521
>> Stopped at  panic+0xfe: addia0,zero,256TIDPIDUID 
>> PR
>> FLAGS PFLAGS  CPU  COMMAND
>>   24243  43192 55 0x2  00  cc
>> *480349  52543  00x11  01  perl
>>  480803  72746 55 0x2  03  c++
>>  366351   3003 55 0x2  02K c++
>> panic() at panic+0xfa
>> panic() at pool_do_get+0x29a
>> pool_do_get() at pool_get+0x76
>> pool_get() at pmap_enter+0x128
>> pmap_enter() at uvm_fault_upper+0x1c2
>> uvm_fault_upper() at uvm_fault+0xb2
>> uvm_fault() at do_trap_user+0x120
>> https://www.openbsd.org/ddb.html describes the minimum info required in bug
>> reports.  Insufficient info makes it difficult to find and fix bugs.
>> ddb{1}> bt
>> panic() at panic+0xfa
>> panic() at pool_do_get+0x29a
>> pool_do_get() at pool_get+0x76
>> pool_get() at pmap_enter+0x128
>> pmap_enter() at uvm_fault_upper+0x1c2
>> uvm_fault_upper() at uvm_fault+0xb2
>> uvm_fault() at do_trap_user+0x120
>> do_trap_user() at cpu_exception_handler_user+0x7a
>> 
>> 
>> The conserver logs for this console provide a hint about when it
>> happened:
>> 
>> --8<--
>> [-- MARK -- Fri Oct  8 08:00:00 2021]
>> [-- MARK -- Fri Oct  8 09:00:00 2021]
>> [-- MARK -- Fri Oct  8 10:00:00 2021]
>> bt
>> ^Mpanic() at panic+0xfa
>> ^Mpanic() at pool_do_get+0x29a
>> ...
>> -->8--
>> 
>> It seems that Theo was plugging/unplugging usb cables at that time.
>> I asked Theo to reboot the machine as I couldn't get more useful output.
>
> Thanks for the heads up.  Some sort of memory corruption, but no real
> clues what caused it.

Another one, maybe a similar cause, maybe not. :-/

[...]
OpenBSD 7.0-current (GENERIC.MP) #84: Mon Oct 18 01:23:24 MDT 2021
dera...@riscv64.openbsd.org:/usr/src/sys/arch/riscv64/compile/GENERIC.MP
[...]
OpenBSD/riscv64 (riscv64.ports.openbsd.org) (console)

login: t[0] == 0x
t[1] == 0xffc00034feb2
t[2] == 0xffc227cd9630
t[3] == 0xffc0008cf1b0
t[4] == 0x0022
t[5] == 0x
t[6] == 0x7c9bd777
s[0] == 0xffc227cd9680
s[1] == 0xffc2229d8d28
s[2] == 0xffc000a5e9a8
s[3] == 0xffc2229ad6a0
s[4] == 0xffc0008ff1f8
s[5] == 0x
s[6] == 0xffc22a21a050
s[7] == 0x
s[8] == 0xffc000a20d30
s[9] == 0xffc000a25718
s[10] == 0xffc000a8f6a0
s[11] == 0xffc000a25714
a[0] == 0x95b8040228044314
a[1] == 0x95b8040228044314
a[2] == 0xffc2229d8d28
a[3] == 0x0001
a[4] == 0xffc023027800
a[5] == 0x
a[6] == 0x0003
a[7] == 0xffc0008cf1a0
sepc == 0xffc0002f043e
sstatus == 0x00020120
stval == 0xff822804431c
scause == 0x000d
panic: Fatal page fault at 0xffc0002f043e: 0xff822804431c
Stopped at  panic+0xfe: addia0,zero,256TIDPIDUID PR
FLAGS PFLAGS  CPU  COMMAND
 469890  40238 550x12  02  sh
*380568  80457 550x12  03K touch
 299235  73888 55 0x2  01  perl
  15710  89701 560x12  00  ftp
panic() at panic+0xfa
panic() at do_trap_supervisor+0x232
dump_regs() at cpu_exception_handler_supervisor+0x78
cpu_exception_handler_supervisor() at pool_put+0x30
pool_put() at ffs_reclaim+0x5c
ffs_reclaim() at VOP_RECLAIM+0x32
VOP_RECLAIM() at vclean+0x122
https://www.openbsd.org/ddb.html describes the minimum info required in bug
reports.  Insufficient info makes it difficult to find and fix bugs.
ddb{3}>


-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: 'BOOTX64.EFI' file issue

2021-10-20 Thread Mark Kettenis 
Do you see any output with the BOOTX64.EFI from 7.0?

[no subject]

2021-10-20 Thread elyes 
>Synopsis:  <6.9 and 7.0 install.* don't boot in uefi mode>
>Category:  <'BOOTX64.EFI' file issue>
>Environment:
System  : OpenBSD 7.0
Details : OpenBSD 7.0 (GENERIC.MP) #232: Thu Sep 30 14:25:29 MDT 
2021
 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64
>Description:

>How-To-Repeat:

>Fix:



dmesg:
OpenBSD 7.0 (GENERIC.MP) #232: Thu Sep 30 14:25:29 MDT 2021
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8468086784 (8075MB)
avail mem = 8195424256 (7815MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb170 (61 entries)
bios0: vendor Intel Corp. version "BLH6710H.86A.0163.2018.1023.1559" date 
10/23/2018
bios0: Intel Corporation DH67BL
acpi0 at bios0: ACPI 4.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC SSDT MCFG HPET
acpi0: wakeup devices P0P1(S4) P0P2(S4) P0P3(S4) P0P4(S4) GBE_(S4) BR20(S3) 
EUSB(S3) USBE(S3) PEX0(S4) BR21(S4) PEX1(S4) PEX2(S4) PEX3(S4) PEX4(S4) 
PEX5(S4) PEX6(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz, 3292.95 MHz, 06-2a-07
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz, 3292.54 MHz, 06-2a-07
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz, 3292.53 MHz, 06-2a-07
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz, 3292.53 MHz, 06-2a-07
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xf800, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P1)
acpiprt2 at acpi0: bus -1 (P0P2)
acpiprt3 at acpi0: bus -1 (P0P3)
acpiprt4 at acpi0: bus -1 (P0P4)
acpiprt5 at acpi0: bus 1 (PEX0)
acpiprt6 at acpi0: bus 2 (BR21)
acpiprt7 at acpi0: bus -1 (PEX1)
acpiprt8 at acpi0: bus -1 (PEX2)
acpiprt9 at acpi0: bus 3 (PEX3)
acpiprt10 at acpi0: bus -1 (PEX4)
acpiprt11 at acpi0: bus -1 (PEX5)
acpiprt12 at acpi0: bus -1 (PEX6)
acpiprt13 at acpi0: bus -1 (PEX7)
acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x
acpicmos0 at acpi0
acpibtn0 at acpi0: PWRB
acpicpu0 at acpi0: C3(350@104 mwait.3@0x20), C2(500@80 mwait.3@0x10), C1(1000@1 
mwait.1), PSS
acpicpu1 at acpi0: C3(350@104 mwait.3@0x20), C2(500@80 mwait.3@0x10), C1(1000@1 
mwait.1), PSS
acpicpu2 at acpi0: C3(350@104 mwait.3@0x20), C2(500@80 mwait.3@0x10), C1(1000@1 
mwait.1), PSS
acpicpu3 at acpi0: C3(350@104 mwait.3@0x20), C2(500@80 mwait.3@0x10), C1(1000@1 
mwait.1), PSS
cpu0: using VERW MDS workaround (except on vmm entry)
cpu0: Enhanced SpeedStep 3292 MHz: speeds: 3300, 3100, 2900, 2700, 2500, 2300, 
2100, 1900, 1700, 1600 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core 2G Host" rev 0x09
inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 2000" rev 0x09
drm0 at inteldrm0
inteldrm0: msi, SANDYBRIDGE, gen 6
"Intel 6 Series MEI" re

Re: NSD exit status 11 on 7.0

2021-10-20 Thread Mischa 

On 2021-10-20 12:33, Florian Obser wrote:

On 2021-10-20 07:55 +02, Otto Moerbeek  wrote:

On Wed, Oct 20, 2021 at 07:47:30AM +0200, Mischa wrote:

Unfortunately our joy was short lived. This morning I noticed a lot 
of
Oct 20 07:44:15 name1 nsd[80814]: server 76410 died unexpectedly with 
status

11, restarting

It looks like there is a potentially fixed in version 4.3.8.

https://github.com/NLnetLabs/nsd/issues/195
https://github.com/NLnetLabs/nsd/issues/189

https://github.com/NLnetLabs/nsd/blob/NSD_4_3_8_REL/doc/ChangeLog
23 August 2021: Wouter
- Fix #189: nsd 4.3.7 crash answer_delegation: Assertion
`query->delegation_rrset' failed.

(Thanx Roger!)


That is not the correct fix, it only hides the problem and worse,
produces wrong results. Please try this, which is the fix for
https://github.com/NLnetLabs/nsd/issues/194

diff --git namedb.c namedb.c
index 06bef71147c..772e038b16d 100644
--- namedb.c
+++ namedb.c
@@ -583,10 +583,13 @@ domain_find_ns_rrsets(domain_type* domain,
zone_type* zone, rrset_type **ns)
 {
/* return highest NS RRset in the zone that is a delegation above */
domain_type* result = NULL;
+   rrset_type* rrset = NULL;
while (domain && domain != zone->apex) {
-   *ns = domain_find_rrset(domain, zone, TYPE_NS);
-   if (*ns)
+   rrset = domain_find_rrset(domain, zone, TYPE_NS);
+   if (rrset) {
+   *ns = rrset;
result = domain;
+   }
domain = domain->parent;
}



Thanx Florian!
Will give that a go and let you know.

Mischa







As far as I can tell from the things Martijn found it might be the 
case.


Will give that a try and report back.

Mischa


Are you going to try just the one line fix or the whole of 4.3.8?
I suppose if we want to backport to -stable the one-line fix is
preferred.


Yes, except, we should go with the correct fix above ;) Nothing else is
interesting to backport in 4.3.8 as far as I can tell.



-Otto



I provided an explanation what's going on in
https://github.com/NLnetLabs/nsd/issues/195#issuecomment-947505367
Reproduced here (slightly edited):

712296f (the one-line-fix) only hides the problem, it doesn't fix
anything. The real fix is ba0002e (the diff above).

f.9.1.1.0.0.2.ip6.arpa. is an ENT in ip6.arpa. and so is 2.ip6.arpa.
In line 1420 in query.c we haveq->delegation_domain = 
domain_find_ns_rrsets(

and the unfixed domain_find_ns_rrsets would find the NS RRset for
9.1.1.0.0.2.ip6.arpa.

But it would then continue searching upwards, overwriting *ns which is
&q->delegation_rrset. Until it hits 2.ip6.arpa. which has no NS
records. So q->delegation_rrset = NULL but at the same time result !=
NULL because we did find a delegation RRset along the way, we just
ignored it (at least for 9.1.1.0.0.2.ip6.arpa., I didn't check if there
was one further up).

domain_find_ns_rrsets returns non-NULL which means we found a
delegation, but at the same time it doesn't give us the delegation NS
RRset.

It is probably best to revert 712296f since on its own it produces 
wrong

results. I.e. adding it to 4.3.7 gives this:

$ dig @192.168.178.219 +norec f.9.1.1.0.0.2.ip6.arpa NS

; <<>> dig 9.10.8-P1 <<>> @192.168.178.219 +norec 
f.9.1.1.0.0.2.ip6.arpa NS

; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10923
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;f.9.1.1.0.0.2.ip6.arpa.INNS

;; AUTHORITY SECTION:
ip6.arpa.3600INSOAb.ip6-servers.arpa.
nstld.iana.org. 2021100154 1800 900 604800 3600

;; Query time: 0 msec
;; SERVER: 192.168.178.219#53(192.168.178.219)
;; WHEN: Wed Oct 20 10:24:56 CEST 2021
;; MSG SIZE  rcvd: 115

But the correct answer is this:

dig @::1 +norec  f.9.1.1.0.0.2.ip6.arpa NS

; <<>> dig 9.10.8-P1 <<>> @::1 +norec f.9.1.1.0.0.2.ip6.arpa NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48090
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;f.9.1.1.0.0.2.ip6.arpa.INNS

;; AUTHORITY SECTION:
9.1.1.0.0.2.ip6.arpa.86400INNSr.arin.net.
9.1.1.0.0.2.ip6.arpa.86400INNSu.arin.net.
9.1.1.0.0.2.ip6.arpa.86400INNSx.arin.net.
9.1.1.0.0.2.ip6.arpa.86400INNSy.arin.net.
9.1.1.0.0.2.ip6.arpa.86400INNSz.arin.net.
9.1.1.0.0.2.ip6.arpa.86400INNSarin.authdns.ripe.net.

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Wed Oct 20 10:24:16 CEST 2021
;; MSG SIZE  rcvd: 171

Re: NSD exit status 11 on 7.0

2021-10-20 Thread Florian Obser 
On 2021-10-20 07:55 +02, Otto Moerbeek  wrote:
> On Wed, Oct 20, 2021 at 07:47:30AM +0200, Mischa wrote:
>
>> Unfortunately our joy was short lived. This morning I noticed a lot of
>> Oct 20 07:44:15 name1 nsd[80814]: server 76410 died unexpectedly with status
>> 11, restarting
>> 
>> It looks like there is a potentially fixed in version 4.3.8.
>> 
>> https://github.com/NLnetLabs/nsd/issues/195
>> https://github.com/NLnetLabs/nsd/issues/189
>> 
>> https://github.com/NLnetLabs/nsd/blob/NSD_4_3_8_REL/doc/ChangeLog
>> 23 August 2021: Wouter
>> - Fix #189: nsd 4.3.7 crash answer_delegation: Assertion
>> `query->delegation_rrset' failed.
>> 
>> (Thanx Roger!)

That is not the correct fix, it only hides the problem and worse,
produces wrong results. Please try this, which is the fix for
https://github.com/NLnetLabs/nsd/issues/194

diff --git namedb.c namedb.c
index 06bef71147c..772e038b16d 100644
--- namedb.c
+++ namedb.c
@@ -583,10 +583,13 @@ domain_find_ns_rrsets(domain_type* domain, zone_type* 
zone, rrset_type **ns)
 {
/* return highest NS RRset in the zone that is a delegation above */
domain_type* result = NULL;
+   rrset_type* rrset = NULL;
while (domain && domain != zone->apex) {
-   *ns = domain_find_rrset(domain, zone, TYPE_NS);
-   if (*ns)
+   rrset = domain_find_rrset(domain, zone, TYPE_NS);
+   if (rrset) {
+   *ns = rrset;
result = domain;
+   }
domain = domain->parent;
}
 

>> 
>> As far as I can tell from the things Martijn found it might be the case.
>> 
>> Will give that a try and report back.
>> 
>> Mischa
>
> Are you going to try just the one line fix or the whole of 4.3.8?
> I suppose if we want to backport to -stable the one-line fix is
> preferred.

Yes, except, we should go with the correct fix above ;) Nothing else is
interesting to backport in 4.3.8 as far as I can tell.

>
>   -Otto
>

I provided an explanation what's going on in
https://github.com/NLnetLabs/nsd/issues/195#issuecomment-947505367
Reproduced here (slightly edited):

712296f (the one-line-fix) only hides the problem, it doesn't fix
anything. The real fix is ba0002e (the diff above).

f.9.1.1.0.0.2.ip6.arpa. is an ENT in ip6.arpa. and so is 2.ip6.arpa.
In line 1420 in query.c we haveq->delegation_domain = domain_find_ns_rrsets(
and the unfixed domain_find_ns_rrsets would find the NS RRset for 
9.1.1.0.0.2.ip6.arpa.

But it would then continue searching upwards, overwriting *ns which is
&q->delegation_rrset. Until it hits 2.ip6.arpa. which has no NS
records. So q->delegation_rrset = NULL but at the same time result !=
NULL because we did find a delegation RRset along the way, we just
ignored it (at least for 9.1.1.0.0.2.ip6.arpa., I didn't check if there
was one further up).

domain_find_ns_rrsets returns non-NULL which means we found a
delegation, but at the same time it doesn't give us the delegation NS
RRset.

It is probably best to revert 712296f since on its own it produces wrong
results. I.e. adding it to 4.3.7 gives this:

$ dig @192.168.178.219 +norec f.9.1.1.0.0.2.ip6.arpa NS

; <<>> dig 9.10.8-P1 <<>> @192.168.178.219 +norec f.9.1.1.0.0.2.ip6.arpa NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10923
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;f.9.1.1.0.0.2.ip6.arpa.INNS

;; AUTHORITY SECTION:
ip6.arpa.3600INSOAb.ip6-servers.arpa. nstld.iana.org. 
2021100154 1800 900 604800 3600

;; Query time: 0 msec
;; SERVER: 192.168.178.219#53(192.168.178.219)
;; WHEN: Wed Oct 20 10:24:56 CEST 2021
;; MSG SIZE  rcvd: 115

But the correct answer is this:

dig @::1 +norec  f.9.1.1.0.0.2.ip6.arpa NS

; <<>> dig 9.10.8-P1 <<>> @::1 +norec f.9.1.1.0.0.2.ip6.arpa NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48090
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;f.9.1.1.0.0.2.ip6.arpa.INNS

;; AUTHORITY SECTION:
9.1.1.0.0.2.ip6.arpa.86400INNSr.arin.net.
9.1.1.0.0.2.ip6.arpa.86400INNSu.arin.net.
9.1.1.0.0.2.ip6.arpa.86400INNSx.arin.net.
9.1.1.0.0.2.ip6.arpa.86400INNSy.arin.net.
9.1.1.0.0.2.ip6.arpa.86400INNSz.arin.net.
9.1.1.0.0.2.ip6.arpa.86400INNSarin.authdns.ripe.net.

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Wed Oct 20 10:24:16 CEST 2021
;; MSG SIZE  rcvd: 171


-- 
I'm not entirely sure you are real.

Re: Fix mkhybrid segfault with -T

2021-10-20 Thread Soner Tari 
Here are the actual prints which helped me debug the issue:

tablesize= 12288
ROUND_UP(tablesize + 1)= 14336
ROUND_UP(tablesize)= 12288

12288 is an exact multiple of 2048 (the sector size), that's why
ROUND_UP() does not change it.

So you see, if we don't add 1 to 12288, ROUND_UP() gives us back the
same tablesize, which does not leave space for the terminating null.

Note also that the tablesize is computed by adding up the lenghts of
the lines in the translation table. So that does not add 1 for null
termination either.

(You have one out of 2048 chances to catch this, so 2048/15 years = 136
per year = 1 mkhybrid per 3 days for 15 years. Just kidding.)


On Tue, 2021-10-19 at 21:21 +0300, Soner Tari wrote:
> > Synopsis:   In certain cases, mkhybrid(8) with -T crashes with
> segmentation fault.
> 
> > Category:   system
> > Environment:
>   System  : OpenBSD 7.0
>   Details : OpenBSD 7.0 (GENERIC.MP) #0: Fri Oct 15 05:21:14
> +03 2021
>soner@obsd70.localdomain:/sys/arch/amd64/compi
> le/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> 
> > Description:
> This issue is due to an omission to allocate space for null
> termination.
> 
> The code allocates tablesize space for the (char *) table field.
> Then,
> on line 520 in tree.c, the table field is used to accumulate the
> lines
> of the translation table. When the loop reaches the last line,
> sprintf() segfaults when it cannot find space for the terminating
> null.
> 
> > How-To-Repeat:
> It is not possible to replicate this issue easily, because the
> tablesize is passed to the ROUND_UP() macro before being passed to
> e_malloc() and memset(). Apparently, ROUND_UP() successfully hides
> this
> null termination issue, while it is trying to adjust for the sector
> size. You should be (un-)lucky enough to catch it (I've been using
> mkhybrid for the past 15 years, and never had any problems).
> 
> > Fix:
> I don't know if this issue is related with OpenBSD or gnu, but the
> following simple patch fixes it.
> 
> --- /usr/src/gnu/usr.sbin/mkhybrid/src/tree.c.origMon Oct 18
> 02:47:25 2021
> +++ /usr/src/gnu/usr.sbin/mkhybrid/src/tree.c Mon Oct 18 05:15:08
> 2021
> @@ -409,8 +409,8 @@
>table->filedir = this_dir;
>table->de_flags|= INHIBIT_JOLIET_ENTRY;
>table->name = strdup("");
> -  table->table = (char *) e_malloc(ROUND_UP(tablesize));
> -  memset(table->table, 0, ROUND_UP(tablesize));
> +  table->table = (char *) e_malloc(ROUND_UP(tablesize + 1));
> +  memset(table->table, 0, ROUND_UP(tablesize + 1));
>  #ifdef APPLE_HYB
>iso9660_file_length  (trans_tbl, table, 0);
>  #else
>

Re: dhcpleased unable to work on CARP interface

2021-10-20 Thread Florian Obser 
On 2021-10-15 15:58 +02, Guy Godfroy  wrote:
> I have to correct what I said on this patch. It works perfectly
> well. The dynamic IP is just added to the interface, it does not
> replace the dummy one. A simple `ifconfig -A` confirms that.

Great, thanks. I have commited this to -current.

>
> I just don't understand why the dynamic IP then replaces the old one
> when I run netstart again. But that's a detail.
>
> Is there a way to make an official patch about that issue?

Unlikely. syspatches are not free, they are quite work intensive and
this is such a corner case.

Sometimes we make a jumbo-syspatch if there are too many annoying
problems discovered in a new subsystem, if that should happen I'll put
this one in. But currently it looks good for dhcpleased ;)

>
> Guy Godfroy
>

-- 
I'm not entirely sure you are real.