[Bug 262493] bc has bad "prompt" for input, breaking 25+ years of FreeBSD behavior

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262493

Marcin Cieślak  changed:

   What|Removed |Added

 CC||sa...@saper.info

--- Comment #2 from Marcin Cieślak  ---
+1 from here, I was very surprised by this after 13.0 upgrade and happy to see
it go away.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 268076] dc(1): crash on window size change

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268076

Bug ID: 268076
   Summary: dc(1): crash on window size change
   Product: Base System
   Version: CURRENT
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: bin
  Assignee: b...@freebsd.org
  Reporter: sa...@saper.info

> dc --version
dc 5.3.3
Copyright (c) 2018-2022 Gavin D. Howard and contributors
Report bugs at: https://git.yzena.com/gavin/bc

This is free software with ABSOLUTELY NO WARRANTY.
> bc --version
bc 5.3.3
Copyright (c) 2018-2022 Gavin D. Howard and contributors
Report bugs at: https://git.yzena.com/gavin/bc

This is free software with ABSOLUTELY NO WARRANTY


I am running -CURRENT as of 75217c2b470 on my laptop and noticed that dc dumps
core on SIGWINCH (I am using x11-wm/dwm as a window manager so this happens
often):

Window size change occurs after 4 is printed:

radziecki> dc
2 2 +
p
4
Memory fault(coredump)


Core was generated by `dc'.
Program terminated with signal SIGSEGV, Segmentation fault.
Address not mapped to object.
#0  terminal_get_size (el=el@entry=0x0, lins=lins@entry=0x3cd5864c5b1c,
cols=cols@entry=0x3cd5864c5b18)
at /usr/src/contrib/libedit/terminal.c:931
--Type  for more, q to quit, c to continue without paging--
931 *cols = Val(T_co);
(gdb) bt
#0  terminal_get_size (el=el@entry=0x0, lins=lins@entry=0x3cd5864c5b1c,
cols=cols@entry=0x3cd5864c5b18)
at /usr/src/contrib/libedit/terminal.c:931
#1  0x3cd587453ff8 in el_resize (el=0x0) at
/usr/src/contrib/libedit/el.c:614
#2  
#3  _read () at _read.S:4
#4  0x3ccd6561e351 in bc_read_chars (vec=0x3ccd65626848 ,
prompt=0x3ccd655f297c ">>> ")
at /usr/src/contrib/bc/src/read.c:165
#5  bc_read_line (vec=0x3ccd65626848 , prompt=0x3ccd655f297c ">>> ")
at /usr/src/contrib/bc/src/read.c:238
#6  0x3ccd65622c0b in bc_vm_readLine (clear=) at
/usr/src/contrib/bc/src/vm.c:1053
#7  bc_vm_stdin () at /usr/src/contrib/bc/src/vm.c:1099
#8  0x3ccd65621e9d in bc_vm_exec () at /usr/src/contrib/bc/src/vm.c:1420
#9  bc_vm_boot (argc=1, argv=0x3cd5864c62d0) at
/usr/src/contrib/bc/src/vm.c:1570
#10 0x3ccd65606334 in main (argc=1, argv=0x3cd5864c62d0) at
/usr/src/contrib/bc/src/bc.c:60
(gdb) frame 4
#4  0x3ccd6561e351 in bc_read_chars (vec=0x3ccd65626848 ,
prompt=0x3ccd655f297c ">>> ")
at /usr/src/contrib/bc/src/read.c:165
165 r = read(STDIN_FILENO, vm.buf + vm.buf_len,
(gdb) p vm.history
$1 = {el = 0x0, hist = 0x0, badTerm = false}

vm.history.el seems to be zero at this point.

bc, however, behaves different, and frankly I must say I don't like its error
handling that obscures things:

radziecki> gdb /usr/bin/bc
GNU gdb (GDB) 12.1 [GDB v12.1 for FreeBSD]
Copyright (C) 2022 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-portbld-freebsd14.0".
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 /usr/bin/bc...
Reading symbols from /usr/lib/debug//usr/bin/bc.debug...
(gdb) run
Starting program: /usr/bin/bc 
warning: Could not load shared library symbols for [vdso].
Do you need "set solib-search-path" or "set sysroot"?
2+2
4

Fatal error: I/O error
Function: (main)

[Inferior 1 (process 26153) exited with code 04]

After a bit of digging I figured out I had to do this:

(gdb) b bc_vm_handleError
Breakpoint 1 at 0x1050c87: file /usr/src/contrib/bc/src/vm.c, line 311.
(gdb) run
Starting program: /usr/bin/bc 
warning: Could not load shared library symbols for [vdso].
Do you need "set solib-search-path" or "set sysroot"?
2+2
4

Breakpoint 1, bc_vm_handleError (e=BC_ERR_FATAL_IO_ERR, line=0) at
/usr/src/contrib/bc/src/vm.c:311
311 uchar id = bc_err_ids[e];
(gdb) bt
#0  bc_vm_handleError (e=BC_ERR_FATAL_IO_ERR, line=0) at
/usr/src/contrib/bc/src/vm.c:311
#1  0x01036482 in bc_history_line (h=, vec=0x1057848
, prompt=0x102397c ">>> ")
at /usr/src/contrib/bc/src/history.c:268
#2  0x0104f194 in bc_read_line (vec=0x1057848 ,
prompt=)
at /usr/src/contrib/bc/src/read.c:236
#3  0x01053c0b in bc_vm_readLine (clear=) at
/usr/src/contrib/bc/src/vm.c:1053
#4  bc_vm_stdin () at /usr/src/contrib/bc/src/vm.c:1099
#5  0x01052e9d in bc_vm_exec () at /usr/src/contrib/bc/src/vm.c:1420
#6  bc_vm_boot (argc=1, argv=0x7fffe6d0) at
/usr/src/contrib/bc/src/vm.c:1570
#7  0

[Bug 268076] dc(1): crash on window size change

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268076

Marcin Cieślak  changed:

   What|Removed |Added

   See Also||https://bugs.freebsd.org/bu
   ||gzilla/show_bug.cgi?id=2640
   ||10

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 268076] dc(1): crash on window size change

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268076

Piotr Pawel Stefaniak  changed:

   What|Removed |Added

 CC||ps...@freebsd.org

--- Comment #1 from Piotr Pawel Stefaniak  ---
Can you try the newest release from the upstream?
https://git.yzena.com/gavin/bc/tags

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 243401] [patch] ahci driver problems with Marvell 88SE9230 (Dell BOSS-S1)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243401

Dave Cottlehuber  changed:

   What|Removed |Added

Version|12.2-RELEASE|13.1-RELEASE
URL||https://www.dell.com/suppor
   ||t/manuals/de-at/boss-s-1/bo
   ||ss_s1_ug_publication/overvi
   ||ew

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 268076] dc(1): crash on window size change

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268076

--- Comment #2 from Marcin Cieślak  ---
I have tried both 6.1.1 and the master as of
https://git.yzena.com/gavin/bc/src/commit/f4816582b1264b64566fc162ef6512601077cc63

Used ./configure.sh --enable-editline --debug

The behaviour of both dc and bc built from the git repo is the same as
described above.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 268076] dc(1): crash on window size change

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268076

Gavin D. Howard  changed:

   What|Removed |Added

 CC||gavin.d.how...@gmail.com

--- Comment #3 from Gavin D. Howard  ---
Author of the bc/dc here.

I have reproduced this behavior. A couple notes first.

I don't think bc's error handling "obscures" things. When it outputs the error
it did, that's because there *was* an I/O error, but one on either `stdin`,
`stdout`, or `stderr`. Handling terminal stuff requires a lot of I/O, and if
any of it fails, especially since it would have happened on one of the standard
streams that should nearly always work, bc/dc has to assume that something has
gone terribly wrong, so it quits with a complaint.

But the error handling is actually the same between the calculators, so dc
should not have acted differently from bc if history were activated.

That was the problem: in dc, history is *not* activated by default. The bug is
that el_resize() was called anyway, despite not being initialized.

I have pushed a commit (https://git.yzena.com/gavin/bc/commit/19f8e4f325f538)
that fixes the crash. That seems to have fixed the problem.

Can you pull my changes and test that it works for you? You will need to build
like so:

```
./configure -e -gO0
make
```

And the built programs will be `bin/bc` and `bin/dc`.

By the way, if you want to activate history in dc, you need to set the
`DC_TTY_MODE` environment variable to a non-zero integer value. The reason it
is not activated by default is because that's the behavior of the old dc.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 261024] regdomain.xml refers to non-existent http://ftp.ics.uci.edu/pub/ietf/http/related/iso3166.txt for a complete list of country/region codes

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261024

Graham Perrin  changed:

   What|Removed |Added

 Blocks||263315
   Keywords||needs-patch
   Assignee|b...@freebsd.org|grahamper...@freebsd.org
 CC||d...@freebsd.org
 Status|New |Open

--- Comment #3 from Graham Perrin  ---

directs readers to regdomain.xml for correctness. 

Then, regdomain.xml describes itself as (partly) incomplete, and directs
readers to the iso3166.txt file for completeness. 

Then, the iso3166.txt file does not exist. 

Let's make this file xml useful, not a source of frustration :-)

I'll: 

* remove the dead link

* add links to the GeoNames page, and this bug report.


Referenced Bugs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263315
[Bug 263315] [meta] FreeBSD Handbook Revamp
-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 268076] dc(1): crash on window size change

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268076

--- Comment #4 from Marcin Cieślak  ---
Thank you for a very quick response, here is how it looks now:

dc(1) prints "ready for more input" every time I resize the window, but does
not crash at all

radziecki> ./bin/dc  
2 2 + p
4
ready for more input
5 # resize
ready for more input
ready for more input
ready for more input

bc(1) exists as before

radziecki> ./bin/bc
>>> 2 + 2 
4
>>> 
Fatal error: I/O error
Function: (main)



This is your software and I fully respect your right to design its features as
you see fit, especially given the maintenance burden is mostly on you.

I think classic "perror()" would be slighly better here (of course without all
the i18n goodies).

diff --git a/src/history.c b/src/history.c
index bc15da5b..15e6e25b 100644
--- a/src/history.c
+++ b/src/history.c
@@ -264,8 +264,7 @@ bc_history_line(BcHistory* h, BcVec* vec, const char*
prompt)
// If this is true, there was an error. Otherwise, it's just
EOF.
if (len == -1)
{
-   if (errno == ENOMEM) bc_err(BC_ERR_FATAL_ALLOC_ERR);
-   bc_err(BC_ERR_FATAL_IO_ERR);
+   perror("reading next input line failed");
}
else
{

Maybe it could be helpful to tell you how I approached the problem.
This is just my personal story and certainly not a case for everyone
approaching unknown software:

1. First I did 

git grep "Fatal error"

to find out there is i18n system in place and it looks like "I/O Error" is an
error number 5 (counted by hand in "bc_err_msgs")

2. Then I did

git grep bc_err_msgs

to learn that the whole i18n thing is initialized via bc_vm_defaultMsgs()
but still no clue regarding what might have caused it

3. Then tried my luck to

git grep bc_err_ids

that reveals there is bc_vm_handleError() and the name looks promising

4. Having learned that it was easier:

(gdb) b bc_vm_handleError
Breakpoint 1 at 0x2372f8: file ./src/vm.c, line 351.
(gdb) run
Starting program: /usr/home/saper/src/bc/bin/bc 
warning: Could not load shared library symbols for [vdso].
Do you need "set solib-search-path" or "set sysroot"?
>>> 
Breakpoint 1, bc_vm_handleError (e=BC_ERR_FATAL_IO_ERR, line=0) at
./src/vm.c:351
351 uchar id = bc_err_ids[e];
(gdb) bt
#0  bc_vm_handleError (e=BC_ERR_FATAL_IO_ERR, line=0)
at ./src/vm.c:351
#1  0x00218169 in bc_history_line (
h=0x23e440 , vec=0x23e228 , 
prompt=0x201ca5 ">>> ") at ./src/history.c:268
#2  0x00234e10 in bc_read_line (
vec=0x23e228 , prompt=0x201ca5 ">>> ")
at ./src/read.c:236
#3  0x0023827e in bc_vm_readLine (clear=true)
at ./src/vm.c:1114
#4  0x0023ac20 in bc_vm_stdin () at ./src/vm.c:1165
#5  0x00239b7d in bc_vm_exec () at ./src/vm.c:1501
#6  0x00238eae in bc_vm_boot (argc=1, argv=0x7fffe6b0)
at ./src/vm.c:1691
#7  0x0021131c in bc_main (argc=1, argv=0x7fffe6b0)
at ./src/bc.c:62
#8  0x0021a199 in main (argc=1, argv=0x7fffe6b0)
at ./src/main.c:108
(gdb) down
Bottom (innermost) frame selected; you cannot go down.
(gdb) up
#1  0x00218169 in bc_history_line (h=0x23e440 , 
vec=0x23e228 , prompt=0x201ca5 ">>> ")
at ./src/history.c:268
268 bc_err(BC_ERR_FATAL_IO_ERR);
(gdb) list -
263 {
264 // If this is true, there was an error. Otherwise, it's
just EOF.
265 if (len == -1)
266 {
267 if (errno == ENOMEM)
bc_err(BC_ERR_FATAL_ALLOC_ERR);
268 bc_err(BC_ERR_FATAL_IO_ERR);
269 }
270 else
271 {
272 bc_file_printf(&vm->fout, "\n");
(gdb) 
253 }
254 }
255 else bc_history_prompt = bc_vm_strdup(prompt);
256 }
257 
258 // Get the line.
259 line = el_gets(h->el, &len);
260 
261 // If there is no line...
262 if (BC_ERR(line == NULL))
(gdb) p line
$1 = 0x0
(gdb) p h->el
$2 = (EditLine *) 0x800a6a000
(gdb) p len
$3 = -1


What certainly would help is some unique identification of the position of the
error in the code (be it __FILE__, __LINE__ if need be). BC_ERR_FATAL_IO_ERR is
thrown in dozen or so places so I can't quickly tell where did it fail.

Since FreeBSD runs optimized binaries, but with debug symbols available, it was
frustrating to see all local variables optimized out, only errno was there:

(gdb) p len
$1 = 
(gdb) p line
$2 = 
(gdb) p h->el
value has been optimized out
(gdb) p errno
$3 = 4

(feel free to move this conversation somewhere else, sadly could not register
at https://git.yzena.com/gavin/bc/)

But again, thank you for building this software for us.

-- 
You are re

[Bug 268076] dc(1): crash on window size change

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268076

--- Comment #5 from Marcin Cieślak  ---
One more datapoint

env BC_TTY_MODE=0 ./bin/bc

behaves like dc on resize:

> env BC_TTY_MODE=0 ./bin/bc
>>> 2 + 2
4
>>> ready for more input
>>> ready for more input
>>>

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 268086] spin lock held too long in icmp6_rip6_input

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268086

Bug ID: 268086
   Summary: spin lock held too long in icmp6_rip6_input
   Product: Base System
   Version: 13.1-RELEASE
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: veg...@tuxpowered.net

Created attachment 238458
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=238458&action=edit
kgdb output

Hello,

I had this kernel crash on 2 of my routers running a GENERIC 13.1-RELEASE-p3
kernel. This is probably related to adding some new tunnels, starting BGP
sessions with BIRD and adding some routes. A few hours after this change the
both routers crashed just minutes apart with identical stack trace. Once the
change was undone, the routers operate stable for days.

I understand that icmp6_rip6_input's job is to deliver ICMP6 packets to open
sockets. In case of my routers the raw sockets would be held by radvd, fping
(from smokeping) and some python program I use as a smokeping replacement.

Looking at the mbuf at frames 33 icmp6_rip6_input, 34 icmp6_input, 35 ip6_input
I can see ICMPv6 Neighbor Solicitation messages.

Please find attached kgdb bt output. I have the whole memory dump and I can get
other data from it if necessary.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 268076] dc(1): crash on window size change

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268076

--- Comment #6 from Gavin D. Howard  ---
I have pushed three more commits.

The first (https://git.yzena.com/gavin/bc/commit/ab3c543ffda9096) should fix
the spurious "ready for more input" problem.

The second is just a style fix.

The third addresses your problem with obscuring errors.

I now understand what you meant. I'm sorry for not understanding what you
meant.

(And I'm not insulted; don't worry.)

Unfortunately, I couldn't do exactly as you suggested because that error will
still be seen by users, so i18n goodies need to stay.

What I *did* do was make it so debug builds will include the C source file and
line for the error.

This will not solve the problem for you, however. I looked at the Makefile for
my bc in FreeBSD
(https://github.com/freebsd/freebsd-src/blob/78bc019d220e05abb5b12f678f9b4a847019bbcc/usr.bin/gh-bc/Makefile),
and it specifically *unsets* debug mode.

Whether FreeBSD uses a debug build on my bc is outside of my pay grade, but
that discussion is certainly something that still belongs here in the FreeBSD
bug tracker. Stefan Esser (@se) would be the one to make that decision. (I'm
adding him to this bug.)

(And I'm sorry that you couldn't register at git.yzena.com; I had so much spam
I had to disable new accounts not made by me.)

But regardless, the latest master of my code will let you make a debug build
with C source and line information. I hope that helps.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 268076] dc(1): crash on window size change

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268076

--- Comment #7 from Gavin D. Howard  ---
Oh, and the third commit I pushed was
https://git.yzena.com/gavin/bc/commit/bcdf1753e6f8cc54a1e61773c554172faf914447
.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 268088] [PATCH] Check MTU of $iface before creating epair in jib script

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268088

Bug ID: 268088
   Summary: [PATCH] Check MTU of $iface before creating epair in
jib script
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Many People
  Priority: ---
 Component: misc
  Assignee: b...@freebsd.org
  Reporter: niece.uptake...@hiu6mpxacf6d.mailer.me

Created attachment 238460
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=238460&action=edit
Patch file for jib script

When the jib script creates the bridge interface that bridge inherits the mtu
setting of $iface. However, when the jib script create the epair interface the
epair interface gets a default mtu of 1500. If the inherited mtu of the bridge
does not match the default mtu of 1500 from the epair interfaces the script
will fail.

This patch checks the mtu of $iface (that will be inherited by the bridge) and
applies that mtu to the two epair interfaces after creation to ensure the mtu
matches and the script succeeds. I didn't see a single ifconfig command that
gives the mtu value so I grep'd it out of the standard ifconfig output.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 261728] If sh became a usable interactive shell, then why can't it tab-autocomplete file.(mine).1.txt and file.(mine).2.txt?

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261728

Piotr Pawel Stefaniak  changed:

   What|Removed |Added

 Status|New |In Progress

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 268092] ixgbe: if_ixv driver have mismatched Rx buffer size and rx_mbuf_sz

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268092

Bug ID: 268092
   Summary: ixgbe: if_ixv driver have mismatched Rx buffer size
and rx_mbuf_sz
   Product: Base System
   Version: 12.2-STABLE
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Many People
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: nkumarab...@gmail.com

If MTU of the if_ixv VF driver is configured between 1501 and 2030, and if a
peer box have bigger MTU and sends a packet bigger than MTU into this guest,
kernel could crashes. 

Here is my understanding :
There are 2 buffers involved for Rx process. One for the DMA(bufsz) and
another(rx_mbuf_sz) for sending that packet to netstack.

In if_ixv driver, bufsz is set to 4096 if MTU is more than the default
MTU: 1500. Whereas rx_mbuf_sz is set to 2048, for upto MTU 2030
(Calculation is based on frame size: 18). Because of this, for MTU upto
1500, both rx_mbuf_sz & bufsz is 2048. And for MTU above 2031,  both 
rx_mbuf_sz & bufsz is 4096. Whereas for MTU 1501 to 2030, rx_mbuf_sz 
will be 2048 and bufsz is 4096. 

So for MTU between 1501 and 2030, if the peer box have bigger MTU and 
sends a bigger packet, there is a mismatch between what's written to 
the Rx buffers and what's sent to netstack. And when that memory beyond
allocated 2048 is accessed, kernel crashes. 

Ideally, bufsz should be based on rx_mbuf_sz (This is calculated right
before configuring Rx settings). 

I could crash the box my setting MTU between 1501 and 2030 and sending sending
8k sized ping packet very consistently and with this below fix to match
bufsz & rx_mbuf_sz, could verify that no crash occurred. 


--- a/sys/dev/ixgbe/if_ixv.c
+++ b/sys/dev/ixgbe/if_ixv.c
@@ -1368,7 +1376,7 @@ ixv_initialize_receive_units(if_ctx_t ctx)
struct ix_rx_queue *que = adapter->rx_queues;
u32bufsz, psrtype;

-   if (if_getmtu(ifp) > ETHERMTU)
+   if (adapter->rx_mbuf_sz > 2048)
bufsz = 4096 >> IXGBE_SRRCTL_BSIZEPKT_SHIFT;
else
bufsz = 2048 >> IXGBE_SRRCTL_BSIZEPKT_SHIFT;

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 268093] killall(1) allow sending signals to pts(4)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268093

Bug ID: 268093
   Summary: killall(1) allow sending signals to pts(4)
   Product: Base System
   Version: Unspecified
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: bin
  Assignee: b...@freebsd.org
  Reporter: freebsd-b...@daemonbytes.net
 Attachment #238465 text/plain
 mime type:

Created attachment 238465
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=238465&action=edit
Patchfile

Hello,

the current version of killall(1) does not allow sending signals to processes
attached to a pts(4) e.g /dev/pts/4 and to do so results in an error messages
like the one below. 

#killall -t pts/4
killall: stat(/dev/ttypts/4): No such file or directory


The provided patch would enable the ability to do that.

Best regards

Daniel Dowse


--- killall.c.orig  2022-12-01 02:47:39.299477000 +0100
+++ killall.c   2022-12-01 02:47:21.503069000 +0100
@@ -257,6 +257,8 @@
snprintf(buf, sizeof(buf), "%s", tty);
else if (strncmp(tty, "tty", 3) == 0)
snprintf(buf, sizeof(buf), "/dev/%s", tty);
+   else if (strncmp(tty, "pts", 3) == 0)
+   snprintf(buf, sizeof(buf), "/dev/%s", tty);
else
snprintf(buf, sizeof(buf), "/dev/tty%s", tty);
if (stat(buf, &sb) < 0)

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 268093] [PATCH] killall(1) allow sending signals to pts(4)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268093

Daniel Dowse  changed:

   What|Removed |Added

Summary|killall(1) allow sending|[PATCH] killall(1) allow
   |signals to pts(4)   |sending signals to pts(4)

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 268093] [PATCH] killall(1) allow sending signals to pts(4)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268093

Konstantin Belousov  changed:

   What|Removed |Added

 CC||k...@freebsd.org

--- Comment #1 from Konstantin Belousov  ---
It is better to match on pts/, not just pts. For tty, the short match allows
to specify e.g. ttyuX, i.e. USB-serial ports.

Also, there is no need to have two identical snprintfs.

Below is what I intent to commit after your confirmation.

commit e442917ee41986c416afea1d152ad03c5daeeac4
Author: Daniel Dowse 
Date:   Thu Dec 1 04:42:35 2022 +0200

killall(1): allow sending signals to processes with control terminal on
pts(4)

PR: 268093
Reviewed by:kib
MFC after:  1 week

diff --git a/usr.bin/killall/killall.c b/usr.bin/killall/killall.c
index aca0830c158b..494a527d190b 100644
--- a/usr.bin/killall/killall.c
+++ b/usr.bin/killall/killall.c
@@ -255,7 +255,8 @@ main(int ac, char **av)
if (tty) {
if (strncmp(tty, "/dev/", 5) == 0)
snprintf(buf, sizeof(buf), "%s", tty);
-   else if (strncmp(tty, "tty", 3) == 0)
+   else if (strncmp(tty, "tty", 3) == 0 ||
+   strncmp(tty, "pts/", 4) == 0)
snprintf(buf, sizeof(buf), "/dev/%s", tty);
else
snprintf(buf, sizeof(buf), "/dev/tty%s", tty);

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 268093] [PATCH] killall(1) allow sending signals to pts(4)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268093

--- Comment #2 from Daniel Dowse  ---
Hello Konstantin,

thanks you are right. I confirm.

Best regards

Daniel

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 268093] [PATCH] killall(1) allow sending signals to pts(4)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268093

--- Comment #3 from commit-h...@freebsd.org ---
A commit in branch main references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=e442917ee41986c416afea1d152ad03c5daeeac4

commit e442917ee41986c416afea1d152ad03c5daeeac4
Author: Daniel Dowse 
AuthorDate: 2022-12-01 02:42:35 +
Commit: Konstantin Belousov 
CommitDate: 2022-12-01 02:42:35 +

killall(1): allow sending signals to processes with control terminal on
pts(4)

PR: 268093
Reviewed by:kib
MFC after:  1 week

 usr.bin/killall/killall.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

-- 
You are receiving this mail because:
You are the assignee for the bug.