Search

[orklemerkle]

Bug report time! I think there are enough details to merit opening a new thread for this.

Continuing the discussion from Wowlet v3.0.0 Released - update peps! 😎:

As reported by @trichom on the other thread, the official Linux x86_64 binary for Wowlet v3.0.0 crashes SIGILL on a machine that does not support AVX. We tracked it down to a `vmovaps` instruction in what I think is one of the static initialization functions.

trichom reported that the Windows binary, howver, ran fine under Wine on the same system.

@dsc, I figured you'd be the one to contact about Wowlet. Could you please take a look into this?

---

P.S. It might help to have concise instructions for building Wowlet from source. Also, having debug symbols--even in a separate file--for release binaries would greatly assist with debugging.

[dsc]

Heh' nice find.

Building a version of wowlet can be done using these instructions that I use myself when making a release: BUILDING.md#linux-reproducible](https://git.wownero.com/wowlet/wowlet/src/branch/master/docs/BUILDING.md#linux-reproducible). There is also [HACKING.md#documentation-for-developers

I have no idea how to solve this btw, but ill ask around.

[orklemerkle]

Thanks!

Ah, yes that's my mistake. I didn't think to look in the `docs` directory.

I think an explicit `-march=x86-64` for gcc should maintain compatibility all the way back to the first AMD64 CPU. All static dependencies will have to be built with it too, which might be a pain with all the different build systems they use.

While researching this bug I came across pytorch#38094, which uses `qemu-user` to emulate an AVX-less CPU. That might help for testing the fixes.

[qvqc]

dunno if this is avx related.  getting the same issue after building fresh wowlet from source, seeing similar from gdb/backtrace/etc but my processor supports avx

this is different than the other linux bug where wowlet crashes right after completing the wizard.. which is what was happening for me until trying to recompile today.  previous version before hardfork built an ran with out issue

[orklemerkle]

I just tested this on two VMs (on Qemu/KVM), one configured with AVX and one without. With AVX I got to the greeting screen, but without, wowlet crashed at the same location as originally reported.

For reference, here's my disassembly of the crashing instruction (note att syntax):

```
(gdb) disassemble $rip,+32
Dump of assembler code from 0x5555557e935b to 0x5555557e937b:
=> 0x00005555557e935b:   vmovaps (%r12),%xmm0
   0x00005555557e9361:   mov    %rbx,%rax
   0x00005555557e9364:   vmovaps %xmm0,(%rbx)
   0x00005555557e9368:   pop    %rbx
   0x00005555557e9369:   pop    %rbp
   0x00005555557e936a:   pop    %r12
   0x00005555557e936c:   retq  
   0x00005555557e936d:   mov    %rbp,%rdi
   0x00005555557e9370:   callq  0x555556c57d30
   0x00005555557e9375:   lea    0x51ff244(%rip),%r12        # 0x55555a9e85c0
```

The executable was loaded at `0x0000555555554000`.

[qvqc]

this is what i get from my local build.  copied the commands in the other thread

>
> $ ldd ./wowlet
>    linux-vdso.so.1 (0x00007ffc4cdee000)
>    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f96c1fa6000)
>    libX11-xcb.so.1 => /lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007f96c1fa1000)
>    libxcb-icccm.so.4 => /lib/x86_64-linux-gnu/libxcb-icccm.so.4 (0x00007f96c1f9a000)
>    libxcb-image.so.0 => /lib/x86_64-linux-gnu/libxcb-image.so.0 (0x00007f96c1d95000)
>    libxcb-shm.so.0 => /lib/x86_64-linux-gnu/libxcb-shm.so.0 (0x00007f96c1d90000)
>    libxcb-keysyms.so.1 => /lib/x86_64-linux-gnu/libxcb-keysyms.so.1 (0x00007f96c1d8b000)
>    libxcb-randr.so.0 => /lib/x86_64-linux-gnu/libxcb-randr.so.0 (0x00007f96c1d76000)
>    libxcb-render-util.so.0 => /lib/x86_64-linux-gnu/libxcb-render-util.so.0 (0x00007f96c1d6f000)
>    libxcb-render.so.0 => /ligb/x86_64-linux-gnu/libxcb-render.so.0 (0x00007f96c1d60000)
>    libxcb-shape.so.0 => /lib/x86_64-linux-gnu/libxcb-shape.so.0 (0x00007f96c1d5b000)
>    libxcb-sync.so.1 => /lib/x86_64-linux-gnu/libxcb-sync.so.1 (0x00007f96c1d51000)
>    libxcb-xfixes.so.0 => /lib/x86_64-linux-gnu/libxcb-xfixes.so.0 (0x00007f96c1d47000)
>    libxcb-xkb.so.1 => /lib/x86_64-linux-gnu/libxcb-xkb.so.1 (0x00007f96c1d27000)
>    libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f96c1cfd000)
>    libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x00007f96c1bc0000)
>    libxkbcommon-x11.so.0 => /lib/x86_64-linux-gnu/libxkbcommon-x11.so.0 (0x00007f96c1bb5000)
>    libxkbcommon.so.0 => /lib/x86_64-linux-gnu/libxkbcommon.so.0 (0x00007f96c1b73000)
>    libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f96c1a4a000)
>    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f96c18f9000)
>    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f96c18d6000)
>    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f96c16e4000)
>    /lib64/ld-linux-x86-64.so.2 (0x00007f96c77ec000)
>    libxcb-util.so.1 => /lib/x86_64-linux-gnu/libxcb-util.so.1 (0x00007f96c14de000)
>    libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007f96c14d8000)
>    libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f96c14ce000)
>    libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f96c145b000)
>    libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f96c1441000)
>
>
> $ ./wowlet; echo $?
> Illegal instruction (core dumped)
> 132
>
>
> (gdb) run
> Starting program: /home/qvqc/projects/wowlet/wowlet
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>
> Program received signal SIGILL, Illegal instruction.
> 0x00005555565de909 in ?? ()
> (gdb) backtrace
> #0  0x00005555565de909 in ?? ()
> #1  0x00005555557ea8ae in ?? ()
> #2  0x0000555556cf30cd in ?? ()
> #3  0x00007ffff770c040 in __libc_start_main (main=0x5555557c20a0, argc=1, argv=0x7fffffffe0f8, init=0x555556cf3080, fini=, rtld_fini=, stack_end=0x7fffffffe0e8) at ../csu/libc-start.c:264
> #4  0x00005555557ee5f9 in ?? ()
> (gdb
>
> fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes **xsave** **avx** f16c rdrand lahf_lm cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts md_clear flush_l1d


this is whats seen from the official build, it crashes right after selecting the wallet in the start wizard and clicking open

> qvqc@qvqc:~/projects/wowlet$ ldd ./wowlet-3
>    linux-vdso.so.1 (0x00007fff2c996000)
>    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f696b4b6000)
>    libX11-xcb.so.1 => /lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007f696b4b1000)
>    libxcb-icccm.so.4 => /lib/x86_64-linux-gnu/libxcb-icccm.so.4 (0x00007f696b4aa000)
>    libxcb-image.so.0 => /lib/x86_64-linux-gnu/libxcb-image.so.0 (0x00007f696b2a5000)
>    libxcb-shm.so.0 => /lib/x86_64-linux-gnu/libxcb-shm.so.0 (0x00007f696b2a0000)
>    libxcb-keysyms.so.1 => /lib/x86_64-linux-gnu/libxcb-keysyms.so.1 (0x00007f696b29b000)
>    libxcb-randr.so.0 => /lib/x86_64-linux-gnu/libxcb-randr.so.0 (0x00007f696b286000)
>    libxcb-render-util.so.0 => /lib/x86_64-linux-gnu/libxcb-render-util.so.0 (0x00007f696b27f000)
>    libxcb-render.so.0 => /lib/x86_64-linux-gnu/libxcb-render.so.0 (0x00007f696b270000)
>    libxcb-shape.so.0 => /lib/x86_64-linux-gnu/libxcb-shape.so.0 (0x00007f696b26b000)
>    libxcb-sync.so.1 => /lib/x86_64-linux-gnu/libxcb-sync.so.1 (0x00007f696b261000)
>    libxcb-xfixes.so.0 => /lib/x86_64-linux-gnu/libxcb-xfixes.so.0 (0x00007f696b257000)
>    libxcb-xkb.so.1 => /lib/x86_64-linux-gnu/libxcb-xkb.so.1 (0x00007f696b237000)
>    libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f696b20d000)
>    libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x00007f696b0d0000)
>    libxkbcommon-x11.so.0 => /lib/x86_64-linux-gnu/libxkbcommon-x11.so.0 (0x00007f696b0c5000)
>    libxkbcommon.so.0 => /lib/x86_64-linux-gnu/libxkbcommon.so.0 (0x00007f696b083000)
>    libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f696af5a000)
>    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f696ae09000)
>    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f696ade6000)
>    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f696abf4000)
>    /lib64/ld-linux-x86-64.so.2 (0x00007f6970cfb000)
>    libxcb-util.so.1 => /lib/x86_64-linux-gnu/libxcb-util.so.1 (0x00007f696a9ee000)
>    libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007f696a9e8000)
>    libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f696a9de000)
>    libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f696a96b000)
>    libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f696a951000)
> qvqc@qvqc:~/projects/wowlet$ gdb ./wowlet-3
> GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2
> Copyright (C) 2020 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
>     <http://www.gnu.org/software/gdb/documentation/>.
>
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from ./wowlet-3...
> (No debugging symbols found in ./wowlet-3)
> (gdb) run
> Starting program: /home/qvqc/projects/wowlet/wowlet-3
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> [New Thread 0x7ffff6ecc700 (LWP 2443971)]
> Mode: Mainnet
> Qt: 5.15.2
> SSL: OpenSSL 1.1.1i  8 Dec 2020
> SSL build: OpenSSL 1.1.1i  8 Dec 2020
> WOWlet: beta-4
> [New Thread 0x7ffff64ac700 (LWP 2443972)]
> creating  "/home/qvqc/Wownero/wallets"
> configRoot:  "/home/qvqc"
> homeDir:  "/home/qvqc"
> customWalletDir:  ""
> defaultWalletDir:  "/home/qvqc/Wownero/wallets"
> defaultWalletDirRoot:  "/home/qvqc/Wownero"
> configDirectory:  "/home/qvqc/.config/wowlet/"
> "Loaded 12 cached websocket nodes from config"
> Saved node config.
> [New Thread 0x7ffff565f700 (LWP 2443973)]
> [New Thread 0x7ffff4e5e700 (LWP 2443974)]
> [New Thread 0x7fffdffff700 (LWP 2443975)]
> [New Thread 0x7fffdf7fe700 (LWP 2443976)]
> [2021-08-12 22:58:13 C] (:0) 0
> [2021-08-12 22:58:13 I] "1920x1080 (96 DPI)"
> [2021-08-12 22:58:13 D] (:0) Restored window state:  true   true
> [Detaching after fork from child process 2443977]
> [2021-08-12 22:58:13 D] (:0) "Tor versions: embedded 0.4.5.5, filesystem 0.4.5.5"
> [2021-08-12 22:58:13 D] (:0) Writing Tor executable to  "/home/qvqc/.config/wowlet/tor/tor"
> [2021-08-12 22:58:13 D] (:0) Using embedded tor instance
> [2021-08-12 22:58:13 D] (:0) "Start process: /home/qvqc/.config/wowlet/tor/tor"
> [2021-08-12 22:58:13 D] (:0) "/home/qvqc/.config/wowlet/tor/tor --ignore-missing-torrc --SocksPort 127.0.0.1:19450 --TruncateLogFile 1 --DataDirectory /home/qvqc/.config/wowlet/tor/data --Log notice --pidfile /home/qvqc/.config/wowlet/tor/data/tor.pid"
> [Detaching after fork from child process 2443978]
> [2021-08-12 22:58:13 D] (:0) wallet .keys search initiated
> [2021-08-12 22:58:13 D] (:0) "wallet .keys search completed in 1149 ms"
> [2021-08-12 22:58:13 D] (:0) "Aug 12 22:58:13.746 [notice] Tor 0.4.5.5-rc (git-b36a00e9a9d3eb4b) running on Linux with Libevent 2.1.12-stable, OpenSSL 1.1.1i, Zlib 1.2.11, Liblzma N/A, Libzstd N/A and Glibc 2.27 as libc.\nAug 12 22:58:13.746 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning\nAug 12 22:58:13.746 [notice] Configuration file \"/home/qvqc/.torrc\" not present, using reasonable defaults.\nAug 12 22:58:13.749 [notice] Wow!  I detected that you have 24 CPUs. I will not autodetect any more than 16, though.  If you want to configure more, set NumCPUs in your torrc\nAug 12 22:58:13.749 [notice] Opening Socks listener on 127.0.0.1:19450\nAug 12 22:58:13.749 [notice] Opened Socks listener connection (ready) on 127.0.0.1:19450\nAug 12 22:58:13.000 [notice] Bootstrapped 0% (starting): Starting\n"
> [2021-08-12 22:58:13 W] (:0) Tor started, awaiting bootstrap
> [2021-08-12 22:58:14 D] (:0) "Aug 12 22:58:14.000 [notice] Starting with guard context \"default\"\n"
> [2021-08-12 22:58:15 D] (:0) "Aug 12 22:58:15.000 [notice] Bootstrapped 5% (conn): Connecting to a relay\n"
> [2021-08-12 22:58:15 D] (:0) "Aug 12 22:58:15.000 [notice] Bootstrapped 10% (conn_done): Connected to a relay\n"
> [2021-08-12 22:58:18 D] (:0) wallet .keys search initiated
> [2021-08-12 22:58:18 D] (:0) "wallet .keys search completed in 2002 ms"
> [2021-08-12 22:58:25 D] (:0) "Wallet* WalletManager::openWallet(const QString&, const QString&, NetworkType::Type, quint64): opening wallet at /home/qvqc/Wownero/wallets/default.keys, nettype = 0 "
>
> Thread 5 "Thread (pooled)" received signal SIGILL, Illegal instruction.
> [Switching to Thread 0x7ffff4e5e700 (LWP 2443974)]
> 0x00005555566b9fdc in ?? ()
> (gdb) backtrace
> #0  0x00005555566b9fdc in ?? ()
> #1  0x00005555566bb183 in ?? ()
> #2  0x00005555566b8e5c in ?? ()
> #3  0x00005555566b8f1d in ?? ()
> #4  0x0000555556599f91 in ?? ()
> #5  0x0000555556287fa6 in ?? ()
> #6  0x00005555559239d3 in ?? ()
> #7  0x0000555555950401 in ?? ()
> #8  0x0000555555873129 in ?? ()
> #9  0x0000555555873cfc in ?? ()
> #10 0x00005555558c22b7 in ?? ()
> #11 0x0000555555c5a3fd in ?? ()
> #12 0x0000555555c579cf in ?? ()
> #13 0x00007ffff78e0609 in start_thread (arg=) at pthread_create.c:477
> #14 0x00007ffff7807293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

[orklemerkle]

this is what i get from my local build.

I can't debug this without the binary. Would you mind sharing your build?

this is whats seen from the official build, it crashes right after selecting the wallet in the start wizard and clicking open

This one I can reproduce on Sandy Bridge. It crashes on a `rorx` instruction from BMI2, first supported on Intel Haswell and AMD Excavator.

```
(gdb) disassemble $rip,+32
Dump of assembler code from 0x5555566b9fdc to 0x5555566b9ffc:
=> 0x00005555566b9fdc:   rorx   $0x3f,%r15,%r11
   0x00005555566b9fe2:   xor    -0x38(%rsp),%r8
   0x00005555566b9fe7:   xor    -0x8(%rsp),%r8
   0x00005555566b9fec:   xor    %r8,%r11
   0x00005555566b9fef:   rorx   $0x3f,%r8,%r8
   0x00005555566b9ff5:   xor    %r11,%rbx
   0x00005555566b9ff8:   xor    %r11,%rcx
   0x00005555566b9ffb:   xor    %r11,%r9
End of assembler dump.
```

Thanks for the find! While it's not the exact same bug, it shows that this is a general issue with using ISA extensions that not everyone has (yet).

[qvqc]

I can't debug this without the binary. Would you mind sharing your build?

ofc! fwiw, tested on a newer ryzen and it launched without issue. thanks for checking this out
wowlet.tgz

    $ sha256sum wowlet
    d126270fb31b98cf4091ac376ea52472c313f3080c018a9812cca99ca666598e  wowlet



do you know where to add `-march=x86-64`? could try a test build with that. looking at these lines but not sure.. https://git.wownero.com/wowlet/wowlet/src/branch/master/Dockerfile#L3-L5

**edit:** found a recent commit where `-DARCH=x86-64` was removed from the makefile, tried adding it back and things broke

[leonard6]

(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)

[orklemerkle]

@dsc, I haven't been able to reproduce your release builds. I did, however, find that the result varies depending on the build machine's CPU family.

```
522281ac0e54f25b22d6c20f3e5019c16a138094752f8a80bf9f2daf108321c6  conroe/wowlet
9efa63c4ea3c2fdb4876095738aac0d20503719dcde6d7475e4dff9fdefd1f98  haswell/wowlet
9efa63c4ea3c2fdb4876095738aac0d20503719dcde6d7475e4dff9fdefd1f98  broadwell/wowlet
37531b098e6b3693d07a52086a4fb73538437a2f3b15298c810f10e340270700  skylake-client/wowlet
205b77b2078bafffb0e7fa02894b422b39bd08c08c2fa1d8050930423891eb52  skylake-server/wowlet
205b77b2078bafffb0e7fa02894b422b39bd08c08c2fa1d8050930423891eb52  cascadelake-server/wowlet
```

These are Linux x86_64 binaries compiled using the "reproducible" Docker-based build instructions, each time restarting from a fresh OS image. I've tested across different VM configs and distros, and the only difference seems to come varying the CPU.

What CPU did you use? Either I haven't hit your exact CPU model, or dependencies have drifted enough for the builds to no longer match.

Or I might be missing something silly.

The only thing I changed was the Boost download URL in `Dockerfile`, which had moved due to Bintray shutting down. Instead of https://dl.bintray.com/boostorg/release/1.73.0/source/boost_1_73_0.tar.gz, it's now https://boostorg.jfrog.io/artifactory/main/release/1.73.0/source/boost_1_73_0.tar.gz.

---

For everyone trying to replicate, there are a couple of build steps which can cause problems if run from behind a pesky firewall or proxy that chokes on anything but vanilla HTTP or HTTPS:

- The Qt build step downloads code via the `git://` protocol. Try `https://code.qt.io/` instead of `git://code.qt.io/`.
- The same goes for GnuPG--try `https://dev.gnupg.org/source/` instead of `git://git.gnupg.org/`.

These changes have no effect on the resulting binaries.

Running 6 jobs in parallel eats up RAM fast. Have about 10 GB free (about 6 GB physical, swap is fine for the rest), or reduce the parallelism.

**EDITED:** clarify

[orklemerkle]

@qvqc, @trichom, as above, I ended up brute-forcing past this by building Wowlet inside a VM set to emulate a Core 2 (Conroe) processor from 2006. Let's see if it works:

    curl -f -o wowlet.gz https://files.catbox.moe/oth2od.gz && \
    echo f7f2343a975d7fa7ab2630a4f5e2703bd7f3f00f34537e035966e6394af60f6f wowlet.gz | sha256sum -c && \
    gunzip wowlet.gz && \
    echo 522281ac0e54f25b22d6c20f3e5019c16a138094752f8a80bf9f2daf108321c6 wowlet | sha256sum -c && \
    chmod +x wowlet

(Watch out, `curl` does not bother to ask before overwriting files.)

[dsc]

Those results are actually hilarious. It implies the reproducible build is not so reproducible. As for my workstation that I use for docker builds;

```text
processor   : 23
vendor_id   : AuthenticAMD
cpu family   : 23
model      : 8
model name   : AMD Ryzen Threadripper 2920X 12-Core Processor
stepping   : 2
microcode   : 0x800820d
cpu MHz      : 2200.000
cache size   : 512 KB
physical id   : 0
siblings   : 24
core id      : 6
cpu cores   : 12
apicid      : 29
initial apicid   : 29
fpu      : yes
fpu_exception   : yes
cpuid level   : 13
wp      : yes
flags      : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid amd_dcm aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb hw_pstate sme ssbd sev ibpb vmmcall sev_es fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves clzero irperf xsaveerptr arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif overflow_recov succor smca
bugs      : sysret_ss_attrs null_seg spectre_v1 spectre_v2 spec_store_bypass
bogomips   : 6985.90
TLB size   : 2560 4K pages
clflush size   : 64
cache_alignment   : 64
address sizes   : 43 bits physical, 48 bits virtual
power management: ts ttp tm hwpstate cpb eff_freq_ro [13] [14]

```

[qvqc]

it works again!!!  amazinggg :sob:.. thanks for the build tips!

wowlet is best wowlet

[dsc]

Surely this must be because of some kind of CMake option I forgot to include/exclude.

[trichom]

Sadly the windows exe stopped working on Wine for some reason. How is it possible? Could it have something to do with os update? Anyway. Now that wow is mooning, I can't get me a Lambo with no wallet. *#$@*!