Vfree() nonexistent vm area

I’m running into some stability issues that causes the system to completely stop functioning. Probably kernel panic in relation to vfree() nonexistent vm area

Feb 25 05:00:33 tohru kernel: ------------[ cut here ]------------
Feb 25 05:00:33 tohru kernel: Trying to vfree() nonexistent vm area (00000000133da97a)
Feb 25 05:00:33 tohru kernel: WARNING: CPU: 6 PID: 3125480 at mm/vmalloc.c:2567 __vunmap+0x6f/0x280
Feb 25 05:00:33 tohru kernel: Modules linked in: hid_nintendo(OE) ff_memless snd_seq_dummy snd_seq algif_hash af_alg nfnetlink joydev mousedev hid_ro>
Feb 25 05:00:33 tohru kernel:  videobuf2_v4l2 snd_usbmidi_lib videobuf2_common snd_rawmidi snd_seq_device rfkill sysimgblt fb_sys_fops snd_hda_codec >
Feb 25 05:00:33 tohru kernel: CPU: 6 PID: 3125480 Comm: Discord Tainted: P        W  OE     5.14.21-2-MANJARO #1
Feb 25 05:00:33 tohru kernel: Hardware name: System manufacturer System Product Name/PRIME Z270-A, BIOS 1302 03/15/2018
Feb 25 05:00:33 tohru kernel: RIP: 0010:__vunmap+0x6f/0x280
Feb 25 05:00:33 tohru kernel: Code: 4c 3b 6b f0 73 31 48 8b 5b 10 48 85 db 75 f1 48 c7 c7 3c 27 a7 a2 e8 20 82 84 00 4c 89 ee 48 c7 c7 78 e1 b8 a1 e8>
Feb 25 05:00:33 tohru kernel: RSP: 0018:ffffb1304760fe50 EFLAGS: 00010282
Feb 25 05:00:33 tohru kernel: RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000027
Feb 25 05:00:33 tohru kernel: RDX: ffff923f4ed20728 RSI: 0000000000000001 RDI: ffff923f4ed20720
Feb 25 05:00:33 tohru kernel: RBP: 0000000000000000 R08: 0000000000000000 R09: ffffb1304760fc80
Feb 25 05:00:33 tohru kernel: R10: ffffb1304760fc78 R11: ffffffffa22cd188 R12: 0000000000000001
Feb 25 05:00:33 tohru kernel: R13: ffffb13061c45000 R14: ffff92380789be40 R15: 0000000000000000
Feb 25 05:00:33 tohru kernel: FS:  00007f6faa162640(0000) GS:ffff923f4ed00000(0000) knlGS:0000000000000000
Feb 25 05:00:33 tohru kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Feb 25 05:00:33 tohru kernel: CR2: 0000308c002dcc20 CR3: 00000001dad94003 CR4: 00000000003706e0
Feb 25 05:00:33 tohru kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Feb 25 05:00:33 tohru kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Feb 25 05:00:33 tohru kernel: Call Trace:
Feb 25 05:00:33 tohru kernel:  <TASK>
Feb 25 05:00:33 tohru kernel:  v4l2_loopback_close+0x86/0xf0 [v4l2loopback_dc]
Feb 25 05:00:33 tohru kernel:  v4l2_release+0xb8/0xc0 [videodev]
Feb 25 05:00:33 tohru kernel:  __fput+0x8c/0x230
Feb 25 05:00:33 tohru kernel:  task_work_run+0x5c/0x90
Feb 25 05:00:33 tohru kernel:  exit_to_user_mode_prepare+0x16d/0x170
Feb 25 05:00:33 tohru kernel:  syscall_exit_to_user_mode+0x23/0x40
Feb 25 05:00:33 tohru kernel:  do_syscall_64+0x48/0x90
Feb 25 05:00:33 tohru kernel:  entry_SYSCALL_64_after_hwframe+0x44/0xae
Feb 25 05:00:33 tohru kernel: RIP: 0033:0x7f6fbac0782b
Feb 25 05:00:33 tohru kernel: Code: 03 00 00 00 0f 05 48 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 33 fc ff ff 8b 7c 24 0c 41 89 c0 b8 03 00>
Feb 25 05:00:33 tohru kernel: RSP: 002b:00007f6faa161370 EFLAGS: 00000293 ORIG_RAX: 0000000000000003
Feb 25 05:00:33 tohru kernel: RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00007f6fbac0782b
Feb 25 05:00:33 tohru kernel: RDX: 0000000000000002 RSI: 0000000080685600 RDI: 000000000000006a
Feb 25 05:00:33 tohru kernel: RBP: 00007f6faa161450 R08: 0000000000000000 R09: 00007f6faa161127
Feb 25 05:00:33 tohru kernel: R10: 0000000000000000 R11: 0000000000000293 R12: 000000000000006a
Feb 25 05:00:33 tohru kernel: R13: 00007f6faa161400 R14: 0000000000000000 R15: 00007f6fab91b017
Feb 25 05:00:33 tohru kernel:  </TASK>
Feb 25 05:00:33 tohru kernel: ---[ end trace d2f7086d36b18d12 ]---

For some reason it’s trying to free a vm area that doesn’t exist as it calls by mm/vmalloc.c and loopback call trace to v4l2_loopback

This issue is triggered by Wine. If I’m running a game that uses Wine/Proton I run into this issue after a while where everything stops working, while applications slowly crash and close out after some time, leaving me in a vegetative state where I can’t send keystroke inputs to move to TTY Console, just simply can’t access TTY, just total non-responsive system. Even if I do have an active terminal screen open, commands will not work, because it’ll return error like error: sudo not found or something like error: ls not found if I try to run those commands for anything.

I don’t really know why Wine would cause the system to go into a completely inoperable state where everything crashes out and ceases to function at all, but it seems to happen consistently I’ve found with running some games that use Wine. It happens every time I play Rust or MGSV The Phantom Pain for example. – I couldn’t find anything online relating to this except for this mailing list here which deduced the issue being a problem related to Wine. Linux-Kernel Archive: Re: Trying to vfree nonexistent vm area

They state that this is something to do with Wine doing some weird shenanigans. While not specifically like their issue when running a Windows command, but is related in the same issue of any running application that may cause this to happen. Same errors, and consistently with Wine. – Obviously that mailing list comes back with no definitive answers to the issue, and albeit a very old mailing list issue, seem to be an issue still in current modern versions of Wine, either never fixed, or resurfaced issue that’s come back.

These games aren’t even maxing out CPU or RAM usage either, and have plenty memory to run on. GPU is Asus GTX 1070 with at least 8GB of memory, and RAM of at least 32GB, CPU cycle isn’t particularly high either in most cases either. – Without any games running, and just web browser and few tabs open, CPU consumption idles around 19% and RAM around 19% consumption also. With games running CPU consumption can be anywhere of around 40% to 70% depending on how CPU intensive the game is and RAM being around 40% - 60% used when games are running.

Wine is a compatibility layer - translating windows system calls to something equivalent to Linux

As probably correct deducted as reverse enginering game calls to windows function and then translate them into something useful on a LInux system requires an enornous amount of low level knowledge and debugging c code - and you are running into pieces of code in the game(s) where functions calls either has not been translated or are buggy.

It is more likely you can find help on the wine fora - it is next to impossible for us mere mortals to understand what is going on inside those low level world of c-code.

Even still it should not ever cause the entire system to stop functioning. The process should end at the compatibility layer and crash the program that’s currently running. There should be a stop code to halt that process when it runs into a memory error like this, it shouldn’t be going beyond that and terminate the host completely.

Also probably related to issues with dbus not receiving the input/output process correctly with Wine.

Perhaps - but you would have to raise such issue with the wine project - they should know what’s going on in the code - even so they may not know this particular issue.