From nobody Mon Jun 30 00:13:15 2025 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4bVmpW0NsKz5ydSR for ; Mon, 30 Jun 2025 00:13:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4bVmpV2k6bz41mR for ; Mon, 30 Jun 2025 00:13:22 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 55U0DFYr029144; Mon, 30 Jun 2025 03:13:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 55U0DFYr029144 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 55U0DFfP029142; Mon, 30 Jun 2025 03:13:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 30 Jun 2025 03:13:15 +0300 From: Konstantin Belousov To: "Bjoern A. Zeeb" Cc: current@freebsd.org Subject: Re: Illegal instruction (core dumped) Message-ID: References: <357r6812-o83q-42rr-ps01-322458p6pp65@yvfgf.mnoonqbm.arg> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Rspamd-Queue-Id: 4bVmpV2k6bz41mR X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] On Sun, Jun 29, 2025 at 03:33:20PM +0000, Bjoern A. Zeeb wrote: > On Sun, 29 Jun 2025, Konstantin Belousov wrote: > > > On Sat, Jun 28, 2025 at 11:23:01PM +0000, Bjoern A. Zeeb wrote: > > > On Sun, 29 Jun 2025, Konstantin Belousov wrote: > > > > > > > On Sat, Jun 28, 2025 at 05:32:17PM +0000, Bjoern A. Zeeb wrote: > > > > > Hi, > > > > > > > > > > happened in one of my dev VMs: > > > > > > > > > > # more /etc/wpa_supplicant.conf Illegal instruction (core dumped) > > > > > > > > > > As I see nothing in UPDATING in the range from HEAD to the commit I > > > > > rebased --onto b93161a7e38d (downgrade of the kernel) that would > > > > > explain this I am wondering. > > > > > > > > > > > > > > > Mounted the disk image from the base system and checked the core: > > > > > > > > > > Program terminated with signal SIGILL, Illegal instruction. > > > > > (gdb) where > > > > > #0 0x00003fabd04ebeed in tgetflag_sp (sp=0x3fa3ad42f3a0 , id=0x3fa3ad42f3a0 "") at /usr/src/contrib/ncurses/ncurses/tinfo/lib_termcap.c:259 > > > > > #1 0x00003fa3ad404e9e in get_term () at /usr/src/contrib/less/screen.c:1256 > > > > > #2 0x00003fa3ad4042ef in main (argc=1, argv=0x3fabce1f26b8) at /usr/src/contrib/less/main.c:344 > > > > > > > > > > > > > What is the instruction that faulted? > > > > Also show the registers values used by the instruction. > > > > > > I am a bit rusty with this user spaec stuff ;-) Hope the below helps. > > > > > > (gdb) display/i $pc > > > 1: x/i $pc > > > => 0x3fabd04ebeed : cmove %rbx,%rcx > > > > > > > So this is kind of impossible. > > I wonder what's going on; that's #3 of really funky things I am seeing > lately on different machines/VM/arhcitectures/source trees. > > > > The instruction CMOVE is there from the PentiumPro times. It does not > > access any resources except registers. It cannot cause the vmexit on its > > own since it cannot generate exceptions (well perhaps except code fetch > > page fault). The only possible vmexit on this instruction is due to > > external events. But then bhyve does not generate #UD. > > > > BTW was it intel or amd cpu? > > intel > > > Could it be due to any corruption? > > I'll keep a copy of the disk image for now but I need to keep moving and > would love to do a complete installworld/kernel again just to see. > It might be for sure, did it persist between reboots? > > BTW, when I tried gdb inside the VM it dumped core as well; same thing: > > (gdb) display/i $pc > 1: x/i $pc > => 0x828064eed : cmove %rbx,%rcx > > (gdb) info f > Stack level 0, frame at 0x821dde8f0: > rip = 0x828064eed in tgetflag_sp (/usr/src/contrib/ncurses/ncurses/tinfo/lib_termcap.c:259); saved rip = 0x8238b10ef > called by frame at 0x821dde950 > source language c. > Arglist at 0x821dde8e0, args: sp=0xb2fd3634000, id=0xb2fd3634000 "" > Locals at 0x821dde8e0, Previous frame's sp is 0x821dde8f0 > Saved registers: > rbx at 0x821dde8d0, rbp at 0x821dde8e0, r14 at 0x821dde8d8, rip at 0x821dde8e8 > > (gdb) info r > rax 0x828077c30 35031317552 > rbx 0x0 0 > rcx 0xffffffffffffd720 -10464 > rdx 0x821ddf05f 34927931487 > rsi 0xb2fd3634000 12300037865472 > rdi 0xb2fd3634000 12300037865472 > rbp 0x821dde8e0 0x821dde8e0 > rsp 0x821dde8e0 0x821dde8e0 > r8 0xfffffffc 4294967292 > r9 0x3 3 > r10 0x54 84 > r11 0x206 518 > r12 0x1ff63a0 33514400 > r13 0x8238c9488 34956153992 > r14 0x821ddf05f 34927931487 > r15 0x0 0 > rip 0x828064eed 0x828064eed > eflags 0x10246 [ PF ZF IF RF ] > cs 0x43 67 > ss 0x3b 59 > ds 0x3b 59 > es 0x3b 59 > fs 0x13 19 > gs 0x1b 27 > fs_base 0xb2fd329d970 12300034103664 > gs_base 0x0 0 > > (gdb) where > #0 0x0000000828064eed in tgetflag_sp (sp=0xb2fd3634000, id=0xb2fd3634000 "") at /usr/src/contrib/ncurses/ncurses/tinfo/lib_termcap.c:259 > #1 0x00000008238b10ef in _rl_init_terminal_io () from /usr/local/lib/libreadline.so.8 > #2 0x00000008238b19d3 in rl_reset_terminal () from /usr/local/lib/libreadline.so.8 > #3 0x0000000001822313 in init_page_info() () > #4 0x00000000017eb74d in gdb_init() () > #5 0x000000000159d7c3 in ?? () > #6 0x000000000159c7bc in gdb_main(captured_main_args*) () > #7 0x00000000012a87c1 in main () You might try to read the instruction as data using p or x gdb command. I believe disassemble reads the text from the file, but if there is a corruption, the in-memory copy would be the indicator.