Unable to kill process within WSL or Task Manager

[kiwidoggie]

• A brief description

I am trying to run objcopy -O binary InputFile OutputFile

for some reason it bugs out and starts creating a 20+GB file of all 00's on my machine and I cannot kill the process without restarting.

• Expected results
  When I kill the process, it should die. From windows I get the message of ERROR: The process "objcopy" with PID 12392 could not be terminated.
  Reason: Access is denied.

If I use htop and send a sigterm within Bash, it does nothing.

• Actual results (with terminal output if applicable)
• Your Windows build number
  Microsoft Windows [Version 10.0.14393]
• Steps / commands required to reproduce the error
  Run objcopy and it will fail, using it for extracting single segments works fine.
• Strace of the failing command
  No Trace, will not die.
• Required packages and commands to install
  GNU Binutils

[aseering]

Hm... Thanks @kiwidoggie for posting! Do you have a specific example of an object file that has this effect?

Just speculating, but I wonder if objdump tries to create a sparse file and WSL doesn't properly support sparse files? That would explain the 0's...

[kiwidoggie]

Yes, I can attach an object. It's because objcopy tries to create the entire address space and the code that I am compiling is at a high address space so it pads it with 00's until it gets there. But that still shouldn't keep the process from killing. On a Ubuntu VM it creates a ~36GB file mainly with 00's but it does it in under a second and I am able to kill the process mid-creation.
TestFile.zip

[aseering]

Just curious, have you tried doing "kill -9"?

Also, have you ever tried running this command on real Linux but on, for example, a FAT filesystem, or another FS that doesn't support sparse files? Just for a comparison of the behavior.

In Linux in general, it's not possible to kill any process while it's in the middle of a syscall. (Though some syscalls are specified to exit early with a well-known error code in case of certain signals.). If objdump executes a single syscall that forces the disk to write gigabytes of zeroes, that may hang uninterruptibly for a while, depending on the details. WSL is aiming for bug-for-bug compatibility with Linux, so it would be interesting to know what Linux does here.

[kiwidoggie]

On a Ubuntu VM, I am able to kill the process with CTRL+C at any point during the creation of the GB's of 00's. I haven't tried kill -9, but is that equivalent to htop's sigterm? I can see if where WSL gets stuck is a syscall, I'm not sure if gdb works in WSL but I will give it a shot.

[aseering]

kill -9 actually sends a SIGKILL. SIGTERM is a catchable signal; a process can intercept it and decide to ignore it. SIGKILL is not catchable; the process never actually sees it, it tells the kernel to immediately de-schedule the process and free all resources that it's using.

gdb unfortunately doesn't work very well under WSL, though it sometimes works for simple programs. strace works well, though, and it gathers lots of information about syscalls.

[laurent22]

I'm also often having the same problem with vim (under tmux, if it makes a difference). I've tried kill, kill -9 and to stop the process in the Task Manager but nothing will do. When it happens I can see the vim process in Task Manager and it always take about 20% CPU. In top under WSL it says 100%. To sort it out the only way is to reboot my PC.

I've also tried strace -p<pid> but it says that the process doesn't exist, even though kill <pid> indicates that it does.

Any idea how to solve this?

[Uldiniad]

same issues here with repo sync (git and git-remote-http), nothing works to kill the tasks properly. Ctrl + C doesn't kill the background task, so if I relaunch the command it piles up in task manager. Task manager doesn't end tasks, and other commands have failed too. so far I've only been able to kill the task by rebooting windows which is not really acceptable. looking forward to a fix

[Reanmachine]

Having the same problem, wont kill -9 or close from Task Manager.

Edit: It seems to have stopped when I closed the WSL Terminal.

Windows 10 Enterprise
Version 1703 (OS Build 15063.447)

~1 week old install of WSL with just basic buildutils/git/tmux/etc... installed

[benhillis]

Fixed in 1803.

[victor-ruben]

@benhillis This just happened to me on build 1803, can't SIGKILL or via Task Manager a puma ruby process.

[N0xFF]

Actually not fixed in 1803

[onomatopellan]

@N0xFF Since the stat of that process is Z that's probably #1353 and it has been fixed in build 17713.

[N0xFF]

@onomatopellan i will try 17713. Thanks

[monolied]

I have this using dd to a ttyUSB0 (USB serial) interface attached via usbipd, mostly after powersave or hibernate.
Can't kill via HUP, TERM, KILL, 9. Can't Ctrl-C or Ctrl-Z the process, either. usbipd can attach and detach, but no effect on the stuck dd.

usbipd 4.2.0+54.Branch.master.Sha.5b36605535dd52bc3d8a8e4bbaee7f4d480c86ad
WSL-Version: 2.2.4.0
Kernelversion: 5.15.153.1-2
WSLg-Version: 1.0.61
MSRDC-Version: 1.2.5326
Direct3D-Version: 1.611.1-81528511
DXCore-Version: 10.0.26091.1-240325-1447.ge-release
Windows-Version: 10.0.19045.4651

[allanleal]

Tried pkill and variants. What worked for me was killing the Remote Desktop process via Task Manager: