bug report: ksh: incorrect "$@" handling with null (empty) IFS

[avih]

NOTE: I was requested on IRC to post to the list but otherwise I'm
not following it, nor using OpenBSD regularly.
Please CC me for any comment.

uname -a (running inside virtual box):
OpenBSD foo.my.domain 6.7 GENERIC.MP#182 amd64


Run the following command:
/bin/sh -c 'IFS=; args() { printf "[%s]" "$@"; }; args 1 2 3'

Expected result:
[1][2][3]

Actual result:
[1 2 3]


It seems that "$@" in [k]sh with IFS as null combines the arguments
as if it was "$*" when IFS is unset or begins with space, while in
fact the main difference between (quoted) "$@" and $* is that the
former should retain the individual arguments regardless of IFS,
while $* combines them with the first char of IFS (or space if IFS
is unset).

The same issue exists also at pdksh 5.2.14, but not at any other
shell which I tested (dash 5.8 up to master, busybox-ash, bash, ksh93,
mksh, bosh, and others).

As far as I can interpret the POSIX specifications and as far as other
shells which I tested behave, it seems to be a bug in pdksh which is
inherited by OpenBSD ksh.


As an anecdote why this behavior is undesirable, consider the pattern:
while IFS= read -r line; do ...; done

and imagine that `read' was implemented as a function which then
calls another function, e.g.: read() { read_internal "$@"; }

With the current behavior, read_internal will see one argument
"-r line" instead of two: "-r" and "line", and could never work
correctly.

Example of this flow (ignore the general badness of echo):
sh -c 'foo() { for x; do echo [$x]; done; }; bar() { foo "$@"; }; IFS=; bar -r 
line'

prints [-r line] as one argument instead of [-r]<\n>[line]<\n>


Best regards,
Avi Halachmi


I was requested to attach dmesg, so here it is:
---

OpenBSD 6.7 (GENERIC.MP) #182: Thu May  7 11:11:58 MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4278124544 (4079MB)
avail mem = 4135845888 (3944MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xe1000 (10 entries)
bios0: vendor innotek GmbH version "VirtualBox" date 12/01/2006
bios0: innotek GmbH VirtualBox
acpi0 at bios0: ACPI 4.0
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP APIC SSDT
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz, 2208.44 MHz, 06-9e-0a
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,RDRAND,NXE,RDTSCP,LONG,LAHF,ABM,3DNOWP,ITSC,FSGSBASE,AVX2,INVPCID,RDSEED,CLFLUSHOPT,MD_CLEAR,L1DF,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: CPU supports MTRRs but not enabled by BIOS
cpu0: apic clock running at 1000MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz, 2208.44 MHz, 06-9e-0a
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,RDRAND,NXE,RDTSCP,LONG,LAHF,ABM,3DNOWP,ITSC,FSGSBASE,AVX2,INVPCID,RDSEED,CLFLUSHOPT,MD_CLEAR,L1DF,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz, 2208.67 MHz, 06-9e-0a
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,RDRAND,NXE,RDTSCP,LONG,LAHF,ABM,3DNOWP,ITSC,FSGSBASE,AVX2,INVPCID,RDSEED,CLFLUSHOPT,MD_CLEAR,L1DF,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz, 2209.88 MHz, 06-9e-0a
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,RDRAND,NXE,RDTSCP,LONG,LAHF,ABM,3DNOWP,ITSC,FSGSBASE,AVX2,INVPCID,RDSEED,CLFLUSHOPT,MD_CLEAR,L1DF,MELTDOWN
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
cpu4 at mainbus0: apid 4 (application processor)
cpu4: Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz, 2209.71 MHz, 06-9e-0a
cpu4: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,RDRAND,NXE,RDTSCP,LONG,LAHF,ABM,3DNOWP,ITSC,FSGSBASE,AVX2,INVPCID,RDSEED,CLFLUSHOPT,MD_CLEAR,L1DF,MELTDOWN
cpu4: 256KB 64b/line 8-way L2 cache
cpu4: smt 0, core 0, package 1
cpu5 at mainbus0: apid 5 (application processor)
cpu5: Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz, 2218.69 MHz, 06-9e-0a
cpu5: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36

Re: ncmpcpp dumps core when fetching lyrics

[Ashlen]

Ah, my bad. I had wrap=72 and reflow_wrap=72 in neomuttrc and forgot it
would affect output like that. Hopefully this one is better.

GNU gdb (GDB) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-openbsd6.8".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ncmpcpp...done.
[New process 190872]
Core was generated by `ncmpcpp'.
Program terminated with signal SIGBUS, Bus error.
#0  _libc_pthread_mutex_unlock (mutexp=) at 
/usr/src/lib/libc/thread/rthread_mutex.c:246
246 /usr/src/lib/libc/thread/rthread_mutex.c: No such file or directory.
(gdb) bt
#0  _libc_pthread_mutex_unlock (mutexp=) at 
/usr/src/lib/libc/thread/rthread_mutex.c:246
#1  0x05595695fb27 in std::__1::__libcpp_mutex_unlock (__m=0x55a00cce818)
at /usr/src/lib/libcxx/include/__threading_support:266
#2  std::__1::mutex::unlock (this=0x55a00cce818) at 
/usr/src/lib/libcxx/src/mutex.cpp:45
#3  0x05572d3b623d in std::__1::unique_lock::~unique_lock 
(this=)
at /usr/include/c++/v1/__mutex_base:153
#4  Shared >::Resource::~Resource (this=) 
at ./utility/shared_resource.h:29
#5  Lyrics::update (this=0x559775d4400) at screens/lyrics.cpp:236
#6  0x05572d4137d5 in std::__1::__function::__value_func::operator()(BaseScreen*&&) const (
this=0x7f7eef80, __args=) at 
/usr/include/c++/v1/functional:1799
#7  std::__1::function::operator()(BaseScreen*) const 
(this=0x7f7eef80, __arg=0x559775d4400)
at /usr/include/c++/v1/functional:2347
#8  applyToVisibleWindows(std::__1::function) (f=...) at 
screens/screen.cpp:135
#9  0x05572d4f9848 in Status::trace (update_timer=, 
update_window_timeout=)
at status.cpp:233
#10 0x05572d46ae33 in Actions::UpdateEnvironment::run (this=0x7f7ef348, 
update_timer=24,
refresh_window=, mpd_sync=) at actions.cpp:338
#11 0x05572d4cf110 in main (argc=, argv=) at 
ncmpcpp.cpp:217
(gdb) quit

--
https://amissing.link

Re: ncmpcpp dumps core when fetching lyrics

[Ashlen]

Sorry Stuart, I think I accidentally replied to you directly the first
time I sent this. I'm still getting used to neomutt.

On 20/09/11 09:09AM, Stuart Henderson wrote:
> First thing to look for when there's a core dump is to see if you can
> get a useful backtrace. How does the output look from this?
>
> pkg_add gdb
> egdb ncmpcpp ncmpcpp.core
> bt
>
> If the lines output from "bt" don't have function names in,
> rebuild ncmpcpp with "make clean; DEBUG=-g make repackage reinstall"
> and try again.

Hey, thanks for the prompt reply and for explaining what I needed to
do. Out of curiosity, why did you want me to install gdb as opposed to
using the version included in the base system? I did so, yet am unaware
of the difference between them.

Here's the output from egdb after recompiling:

GNU gdb (GDB) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-openbsd6.8".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ncmpcpp...done.
[New process 190872]
Core was generated by `ncmpcpp'.
Program terminated with signal SIGBUS, Bus error.
#0  _libc_pthread_mutex_unlock (mutexp=) at 
/usr/src/lib/libc/thread/rthread_mutex.c:246
246 /usr/src/lib/libc/thread/rthread_mutex.c: No such file or directory.
(gdb) bt
#0  _libc_pthread_mutex_unlock (mutexp=) at 
/usr/src/lib/libc/thread/rthread_mutex.c:246
#1  0x05595695fb27 in std::__1::__libcpp_mutex_unlock (__m=0x55a00cce818)
at /usr/src/lib/libcxx/include/__threading_support:266
#2  std::__1::mutex::unlock (this=0x55a00cce818) at 
/usr/src/lib/libcxx/src/mutex.cpp:45
#3  0x05572d3b623d in std::__1::unique_lock::~unique_lock 
(this=)
at /usr/include/c++/v1/__mutex_base:153
#4  Shared >::Resource::~Resource (this=) 
at ./utility/shared_resource.h:29
#5  Lyrics::update (this=0x559775d4400) at screens/lyrics.cpp:236
#6  0x05572d4137d5 in std::__1::__function::__value_func::operator()(BaseScreen*&&) const (
this=0x7f7eef80, __args=) at 
/usr/include/c++/v1/functional:1799
#7  std::__1::function::operator()(BaseScreen*) const 
(this=0x7f7eef80, __arg=0x559775d4400)
at /usr/include/c++/v1/functional:2347
#8  applyToVisibleWindows(std::__1::function) (f=...) at 
screens/screen.cpp:135
#9  0x05572d4f9848 in Status::trace (update_timer=, 
update_window_timeout=)
at status.cpp:233
#10 0x05572d46ae33 in Actions::UpdateEnvironment::run (this=0x7f7ef348, 
update_timer=24,
refresh_window=, mpd_sync=) at actions.cpp:338
#11 0x05572d4cf110 in main (argc=, argv=) at 
ncmpcpp.cpp:217

--
https://amissing.link

Re: ncmpcpp dumps core when fetching lyrics

[Erling Westenvik]

On Fri, Sep 11, 2020 at 09:09:39AM -, Stuart Henderson wrote:
> On 2020-09-10, Ashlen  wrote:
> > doesn't do anything to fix the issue, so it doesn't seem to be
> > a problem caused by my configs.

Been like that for years on all installations here. Never taken time to
investigate, so thanks for the initiative.

> First thing to look for when there's a core dump is to see if you can
> get a useful backtrace. How does the output look from this?
> 
> pkg_add gdb
> egdb ncmpcpp ncmpcpp.core
> bt

(gdb) bt
#0  _libc_pthread_mutex_unlock (mutexp=) at 
/usr/src/lib/libc/thread/rthread_mutex.c:246
#1  0x0ea982e20277 in std::__1::__libcpp_mutex_unlock (__m=0xea9c55edb98) 
at /usr/src/lib/libcxx/include/__threading_support:266
#2  std::__1::mutex::unlock (this=0xea9c55edb98) at 
/usr/src/lib/libcxx/src/mutex.cpp:45
#3  0x0ea77d9fb21d in ?? ()
#4  0x0ea77da587b5 in ?? ()
#5  0x0ea77db3e808 in ?? ()
#6  0x0ea77daafdf3 in ?? ()
#7  0x0ea77db140d0 in ?? ()
#8  0x0ea77d9b9a21 in ?? ()
#9  0x in ?? ()
(gdb)

> If the lines output from "bt" don't have function names in,
> rebuild ncmpcpp with "make clean; DEBUG=-g make repackage reinstall"
> and try again.

Does rebuild suggestion still apply based on gdb output above?

Erling

Re: [ports] Bug in Alpine TLS patch applied in 6.7 (ports/mail/alpine)

[Stuart Henderson]

On 2020-09-10, Jussi Laako  wrote:
> Hi,
>
> I had a problem that with Thunderbird / mobile clients accessing 
> alpine-based imapd server (imap-uw) over SSL/TLS, eventually the imapd 
> server process goes into busy-loop consuming all possible CPU time. 
> After a while the server was crawling with some tens or hundreds of 
> busy-looping imapd processes.
>
> I found out that this is caused by the TLS patch that was added in 6.7 
> with header "Add workarounds to fix alpine with TLSv1.3". Involving 
> following patch:
> patch-imap_src_osdep_unix_ssl_unix_c
>
> Removing this patch makes the problem go away. So I have to conclude 
> there's a problem in this patch. I suspect it may be related to 
> connection termination time. But I don't know enough about this TLS 
> implementation and API to know how to fix this.
>
>
> Best regards,
>
>   - Jussi
>
>

Which (if any) syspatches do you have - if not all of them, does that
help?

Please reply on ports@ where there's a higher chance the right people
will see your mail (I've set followup-to, hopefully gmane will convert
that into reply-to but I'm not 100% sure..)

Re: strange SMTP interaction with mail.openbsd.org ?

[Claus Assmann]

On Fri, Sep 11, 2020, Leen Besselink wrote:

> I waited longer now and CHUNKING is not in the EHLO banner, but I do see
> QUiT again without sending any emails.

> So even though I had turned it off and on a couple of times, it was probably
> just a coincidence.

Did you get an answer from postmaster@?

It would be interesting to know what is going on.

-- 
Address is valid for this mailing list only, please do not reply
to it direcly, but to the list.

Re: ncmpcpp dumps core when fetching lyrics

[Stuart Henderson]

On 2020-09-10, Ashlen  wrote:
> ktrace(1) suggests to me that it's a pathname issue based on this line:
>
> 33399 ncmpcpp  NAMI  "/home/ashlen/.config/ncmpcpp/lyrics//Porcupine
> Tree - Arriving Somewhere But Not Here.txt"
>
>
> Issuing
>
> $ mv ~/.config/ncmpcpp{,.bak}
>
> doesn't do anything to fix the issue, so it doesn't seem to be
> a problem caused by my configs.
>
>
> ktrace.out can be made available upon request. I didn't include it
> because it's quite long.

First thing to look for when there's a core dump is to see if you can
get a useful backtrace. How does the output look from this?

pkg_add gdb
egdb ncmpcpp ncmpcpp.core
bt

If the lines output from "bt" don't have function names in,
rebuild ncmpcpp with "make clean; DEBUG=-g make repackage reinstall"
and try again.