Re: FW: ls -l Segmentation fault

2024-03-26 Thread Todd C . Miller
On Tue, 26 Mar 2024 12:45:09 -0700, guent...@openbsd.org wrote: > Someone want to craft a diff for ls to handle that (and scan the tree for > other unchecked localtime() calls)? Not sure if > POSIX's ls spec has an out for how to print the time for such a thing. Another option is to just use

Re: FW: ls -l Segmentation fault

2024-03-26 Thread guenther
On Tue, 26 Mar 2024, Peter Fraser wrote: > Ls fault with symbols > > lldb /usr/src/bin/ls/ls > (lldb) target create "/usr/src/bin/ls/ls" > Current executable set to '/usr/src/bin/ls/ls' (x86_64). > (lldb) run -l > run -l > Process 88451 launched: '/usr/src/bin/ls/ls' (x86_64) > total 2176 >

Re: FW: ls -l Segmentation fault

2024-03-26 Thread Todd C . Miller
It appears that localtime(3) is returning NULL and that is being passed to strftime(). This should avoid the crash. - todd Index: bin/ls/print.c === RCS file: /cvs/src/bin/ls/print.c,v retrieving revision 1.40 diff -u -p -u -r1.40

Re: FW: ls -l Segmentation fault

2024-03-26 Thread Peter Fraser
Ls fault with symbols lldb /usr/src/bin/ls/ls (lldb) target create "/usr/src/bin/ls/ls" Current executable set to '/usr/src/bin/ls/ls' (x86_64). (lldb) run -l run -l Process 88451 launched: '/usr/src/bin/ls/ls' (x86_64) total 2176 cx 1 34078976wheel58, 7079544 Dec 31 1969

Re: FW: ls -l Segmentation fault

2024-03-26 Thread Stuart Henderson
On 2024/03/26 19:10, Peter Fraser wrote: > I did check https://www.openbsd.org/anoncvs.html > > It still points to https://www.openbsd.org/anoncvs.html Oh, in the example commands, I see. The actual list of mirrors is below - will fix. > -Original Message- > From: Stuart Henderson >

Re: FW: ls -l Segmentation fault

2024-03-26 Thread Peter Fraser
I did check https://www.openbsd.org/anoncvs.html It still points to https://www.openbsd.org/anoncvs.html -Original Message- From: Stuart Henderson Sent: Tuesday, March 26, 2024 3:07 PM To: Peter Fraser Cc: bugs@openbsd.org Subject: Re: FW: ls -l Segmentation fault On 2024/03/26

Re: FW: ls -l Segmentation fault

2024-03-26 Thread Stuart Henderson
On 2024/03/26 18:49, Peter Fraser wrote: > > I tried to get the source, but I get no response out of > > cvs -qd anon...@anoncvs.ca.openbsd.org:/cvs checkout -rOPENBSD_7_4 -P src That server is no more; see https://www.openbsd.org/anoncvs.html You can do a partial checkout if you prefer, e.g.

FW: ls -l Segmentation fault

2024-03-26 Thread Peter Fraser
I tried to get the source, but I get no response out of cvs -qd anon...@anoncvs.ca.openbsd.org:/cvs checkout -rOPENBSD_7_4 -P src I also tried ssh anoncvs.ca.openbsd.org and ping anoncvs.ca.openbsd.org all three gave no responce -Original Message- From: Omar Polo Sent:

Re: pcidevs_data.h relies on pcireg.h despite not including it.

2024-03-26 Thread Gibson Pilconis
What's the distinction between public and private headers within OpenBSD? I'm not trying to be argumentative I'm just genuinely curious since I can't find any info on what that means in the context of the project on Google. On Tuesday, March 26th, 2024 at 1:40 PM, Mark Kettenis wrote: >

Re: ls -l Segmentation fault

2024-03-26 Thread Stuart Henderson
ls is statically linked, could you build from src with "make DEBUG=-g" and obtain a fresh backtrace? On 2024/03/26 17:59, Peter Fraser wrote: > I never expected it was the number files, I give the number to show that it > was some what of general error that populated lost+found > > Using lldb

Re: ls -l Segmentation fault

2024-03-26 Thread Peter Fraser
I never expected it was the number files, I give the number to show that it was some what of general error that populated lost+found Using lldb (lldb) run -l run -l Process 89184 launched: '/bin/ls' (x86_64) total 2176 cx 1 34078976wheel58, 7079544 Dec 31 1969 #04963796

Re: pcidevs_data.h relies on pcireg.h despite not including it.

2024-03-26 Thread Mark Kettenis
> Date: Tue, 26 Mar 2024 17:08:24 + > From: Gibson Pilconis > > If it was exclusively accessible within the kernel I'd agree that it > probably isn't neccessary, the trouble is that it is also accessible > by userland programs. pcidump is an example of a userland program > that is part of

Re: ls -l Segmentation fault

2024-03-26 Thread Omar Polo
[moving to bugs@] On 2024/03/26 17:15:28 +, Peter Fraser wrote: > For some reason I don't know my partition /var/www got screwed up and there > was a long list in /var/www/lost+found. > > Since I populate /var/www by using rsync from another computer, and I expect > didn't notice the

Re: pcidevs_data.h relies on pcireg.h despite not including it.

2024-03-26 Thread Gibson Pilconis
If it was exclusively accessible within the kernel I'd agree that it probably isn't neccessary, the trouble is that it is also accessible by userland programs. pcidump is an example of a userland program that is part of the OpenBSD project and includes the header, and that file acts as a

Re: pcidevs_data.h relies on pcireg.h despite not including it.

2024-03-26 Thread Stuart Henderson
On 2024/03/25 05:12, Gibson Pilconis wrote: > Hi. > > I'm working on a project that supports OpenBSD and I noticed that > pcidevs_data.h uses > structures defined in pcireg.h but doesn't include the file. As a result, > pcireg.h has to be > included before pcidevs_data.h or else the compiler

mg: endless loop using replace-regexp [PATCH]

2024-03-26 Thread Mark Willson
Hi Folks, The mg command 'regexp-replace "^.*$" ""' enters an endless loop (until memory exhausted). This behaviour also occurs in query-replace-regexp with the "!" option. This is due to a change I suggested to re_forwsrch, that is, not moving dot when the line is empty (re_search.c 1.35). The