Re: Illegal instruction (core dumped)

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 <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.
> 
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 <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 ()

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.