Re: Illegal instruction (core dumped)
- Reply: Konstantin Belousov : "Re: Illegal instruction (core dumped)"
- In reply to: Konstantin Belousov : "Re: Illegal instruction (core dumped)"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 29 Jun 2025 15:33:20 UTC
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 <get_term[termbuf]>, id=0x3fa3ad42f3a0 <get_term[termbuf]> "") 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 <tgetflag_sp+29>: 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. BTW, when I tried gdb inside the VM it dumped core as well; same thing: (gdb) display/i $pc 1: x/i $pc => 0x828064eed <tgetflag_sp+29>: 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 <tgetflag_sp+29> 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 () -- Bjoern A. Zeeb r15:7