Re: grep(1) bug - duplicate output lines
Kyle Evans wrote: > I think this is what we want: > > https://people.freebsd.org/~kevans/grep-color.diff Brilliant! Thanks for the quick response and fix. It works fine for me - I've not managed to break it again :-) > Basically, for --color with . we actually get each individual character > reported, and we can't really coalesce that. (Well, we could, but I'll > leave that for future improvement). Once you hit 32 matches in the same > line, we dump out the first set of matches then check again for any more > that just didn't fit the first time. Unfortunately, that logic wasn't > prepared to avoid terminating the first time in case we have more > matches to output, so we'd terminate, then refill our matches with the > remainder of the line and output the leading context again + terminate > again. Ahh, hence the 'chunks' of coloured sections, and the fact that the longer the line, the more times it was repeated. Will this be MFC'd to 13 and 14? Thanks again, Jamie.
Re: grep(1) bug - duplicate output lines
Jamie Landeg-Jones wrote: > Brilliant! Thanks for the quick response and fix. It works fine for me - > I've not managed to break it again :-) Famous last words "grep -v" now produces duplicate lines! e.g. : | % grep -v sdjdjdjd /COPYRIGHT|head | # @(#)COPYRIGHT 8.2 (Berkeley) 3/21/94 | # @(#)COPYRIGHT 8.2 (Berkeley) 3/21/94 | | | The compilation of software known as FreeBSD is distributed under the | The compilation of software known as FreeBSD is distributed under the | following terms: | following terms: Cheers, Jamie
Re: grep(1) bug - duplicate output lines
On 9/29/23 13:25, Jamie Landeg-Jones wrote: Jamie Landeg-Jones wrote: Brilliant! Thanks for the quick response and fix. It works fine for me - I've not managed to break it again :-) Famous last words "grep -v" now produces duplicate lines! e.g. : Alright, fine, be that way. :-) Try this on top of the existing patch: https://people.freebsd.org/~kevans/grep-color.diff I forgot that -v means it's valid to enter procmatch_match with no matches because that's the very definition of the -v flag. As such, we need to specifically avoid the trailing printline() with the vflag because we already terminated in the first printline(). It also removes the offending code that made me overlook that scenario. Thanks, Kyle Evans
Re: grep(1) bug - duplicate output lines
On 9/29/23 15:37, Kyle Evans wrote: On 9/29/23 13:25, Jamie Landeg-Jones wrote: Jamie Landeg-Jones wrote: Brilliant! Thanks for the quick response and fix. It works fine for me - I've not managed to break it again :-) Famous last words "grep -v" now produces duplicate lines! e.g. : Alright, fine, be that way. :-) Try this on top of the existing patch: https://people.freebsd.org/~kevans/grep-color.diff This should be spelled: https://people.freebsd.org/~kevans/grep-color-addition.diff Sorry
crashinfo fails on 'version'
Hi, saveinfo wrote a good core, but crashinfo bails on it: 'version' has unknown type; cast it to its declared type 'version' has unknown type; cast it to its declared type Unable to find matching kernel for /var/crash/vmcore.1 I've got gdb-13.1_3 installed. Anyone any insights? -- Bjoern A. Zeeb r15:7
Re: crashinfo fails on 'version'
On Fri, Sep 29, 2023, 3:56 PM Bjoern A. Zeeb wrote: > Hi, > > saveinfo wrote a good core, but crashinfo bails on it: > > 'version' has unknown type; cast it to its declared type > 'version' has unknown type; cast it to its declared type > Unable to find matching kernel for /var/crash/vmcore.1 > > I've got gdb-13.1_3 installed. > > Anyone any insights? > What does kgdb say? Iirc crashinfo uses lldb for this. Warner -- > Bjoern A. Zeeb r15:7 > >
Re: crashinfo fails on 'version'
On Fri, 29 Sep 2023, Warner Losh wrote: On Fri, Sep 29, 2023, 3:56 PM Bjoern A. Zeeb wrote: Hi, saveinfo wrote a good core, but crashinfo bails on it: 'version' has unknown type; cast it to its declared type 'version' has unknown type; cast it to its declared type Unable to find matching kernel for /var/crash/vmcore.1 I've got gdb-13.1_3 installed. Anyone any insights? What does kgdb say? Iirc crashinfo uses lldb for this. I would hope the latter was true but: % grep -i lldb /usr/sbin/crashinfo % at least on the version here still very much gdb. I have started to trace and manually called the same commands crashinfo seems to run (without batch). It seems the real problem might be that it cannot find debug symbols inside the VM. I am wondering if there was a way to check for that to make the error messages less cryptic (e.g., maintenance print symbols empty if it does what I would think; I'll hopefully see soon). Also turns out /etc/src.conf on the provided host had WITHOUT_DEBUG_FILES= and even building and installing with -DWITH_DEBUG_FILES does not seem to override that (probably by design), which likely was the reason for no symbols in first place. I'll hopefully have more answers in 20 minutes. Remote debugging wifi less fun than I hoped. /bz -- Bjoern A. Zeeb r15:7
FreeBSD 14.0-BETA4 Now Available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The fourth BETA build of the 14.0-RELEASE release cycle is now available. Installation images are available for: o 14.0-BETA4 amd64 GENERIC o 14.0-BETA4 i386 GENERIC o 14.0-BETA4 powerpc GENERIC o 14.0-BETA4 powerpc64 GENERIC64 o 14.0-BETA4 powerpc64le GENERIC64LE o 14.0-BETA4 powerpcspe MPC85XXSPE o 14.0-BETA4 armv7 GENERICSD o 14.0-BETA4 aarch64 GENERIC o 14.0-BETA4 aarch64 RPI o 14.0-BETA4 aarch64 PINE64 o 14.0-BETA4 aarch64 PINE64-LTS o 14.0-BETA4 aarch64 PINEBOOK o 14.0-BETA4 aarch64 ROCK64 o 14.0-BETA4 aarch64 ROCKPRO64 o 14.0-BETA4 riscv64 GENERIC o 14.0-BETA4 riscv64 GENERICSD Note regarding arm SD card images: For convenience for those without console access to the system, a freebsd user with a password of freebsd is available by default for ssh(1) access. Additionally, the root user password is set to root. It is strongly recommended to change the password for both users after gaining access to the system. Installer images and memory stick images are available here: https://download.freebsd.org/releases/ISO-IMAGES/14.0/ The image checksums follow at the end of this e-mail. If you notice problems you can report them through the Bugzilla PR system or on the -stable mailing list. If you would like to use Git to do a source based update of an existing system, use the "releng/14.0" branch. A summary of changes since 14.0-BETA3 includes: o A fix for a pnwerpc-related panic. o Console output on Raspberry Pi 3B+ and 4B have been silenced at boot. o A fix to freebsd=update(8) had been implemented to avoid restarting sshd(8) when updating the basedir. o Support for hidraw(4) has been added. o Several ZFS-related fixes. o Several VFS-related fixes. o Several miscellaneous fixes and driver updates. A list of changes since 13.2-RELEASE is available in the releng/14.0 release notes: https://www.freebsd.org/releases/14.0R/relnotes/ Please note, the release notes page is not yet complete, and will be updated on an ongoing basis as the 14.0-RELEASE cycle progresses. === Virtual Machine Disk Images === VM disk images are available for the amd64, i386, and aarch64 architectures. Disk images may be downloaded from the following URL (or any of the FreeBSD download mirrors): https://download.freebsd.org/releases/VM-IMAGES/14.0-BETA4/ BASIC-CI images can be found at: https://download.freebsd.org/releases/CI-IMAGES/14.0-BETA4/ The partition layout is: ~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label) ~ 1 GB - freebsd-swap GPT partition type (swapfs GPT label) ~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label) The disk images are available in QCOW2, VHD, VMDK, and raw disk image formats. The image download size is approximately 135 MB and 165 MB respectively (amd64/i386), decompressing to a 21 GB sparse image. Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI loader file is needed for qemu-system-aarch64 to be able to boot the virtual machine images. See this page for more information: https://wiki.freebsd.org/arm64/QEMU To boot the VM image, run: % qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt \ -bios QEMU_EFI.fd -serial telnet::,server -nographic \ -drive if=none,file=VMDISK,id=hd0 \ -device virtio-blk-device,drive=hd0 \ -device virtio-net-device,netdev=net0 \ -netdev user,id=net0 Be sure to replace "VMDISK" with the path to the virtual machine image. === Amazon EC2 AMI Images === FreeBSD/amd64 EC2 AMI IDs can be retrieved from the Systems Manager Parameter Store in each region using the keys: /aws/service/freebsd/amd64/base/ufs/14.0/BETA4 /aws/service/freebsd/amd64/base/zfs/14.0/BETA4 FreeBSD/aarch64 EC2 AMI IDs can be retrieved from the Systems Manager Parameter Store in each region using the keys: /aws/service/freebsd/aarch64/base/ufs/14.0/BETA4 /aws/service/freebsd/aarch64/base/zfs/14.0/BETA4 === Vagrant Images === FreeBSD/amd64 images are not available for this build. === Upgrading === IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT Due to an issue where an existing file had been replaced by a directory with the same name, binary upgrades from 13.2 and earlier using the freebsd-update(8) utility will not work. A patch is currently in the main branch, and expected to be included in supported release branches before the next build. IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT The freebsd-update(8) utility supports binary upgrades of amd64, i386, and aarch64 systems running earlier FreeBSD releases. Systems running earlier FreeBSD releases can upgrade as follows: # freebsd-update upgrade -r 14.0-BETA4 During this process, freebsd-update(8) may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-upda
Re: grep(1) bug - duplicate output lines
Kyle Evans wrote: > Alright, fine, be that way. :-) Try this on top of the existing patch: Sorry! I have this knack of (accidentally) stumbling upon weird-case bugs that usually don't affect anyone! :-) > https://people.freebsd.org/~kevans/grep-color-addition.diff Brilliant That all seems to work now! I'll try not to break anything else! :-) Cheers, Jamie
