pikaur constantly use 100% CPU on WSL

[wangqr]

pikaur -Vq
Pikaur v1.3.1
Pacman v5.1.1 - libalpm v11.0.1

Archlinux is running on Windows Subsystem Linux, on windows 10 1809.

Attached log:

pikaur -S caffe
Reading repository package databases...
Reading local package database...
Resolving AUR dependencies...

:: AUR package will be installed:
 caffe                                                      -> 1.0-14

:: Proceed with installation? [Y/n]
:: [v]iew package details   [m]anually select packages
>>

Just leave it there without answering anything. Open htop and I can see that pikaur is using 100% CPU (full of a single core). caffe can be changed to any package.

I ran pikaur with PyCharm profiler, and get the following image:

[wangqr]

And the original pstat file from the profiler:
pikaur5.zip

[actionless]

please run pikaur with --debug flag and hit Ctrl+C while it happens to see the stack trace

[actionless]

but profiling results are confusing for me,

  ncalls  tottime  percall  cumtime  percall filename:lineno(function)
       28   66.495    2.375   66.495    2.375 {method 'acquire' of '_thread.lock' objects}

it saying what each acquiring of the lock was taking more than 2 seconds

can you reproduce it in any other environment? i don't have windows for reproducing it

[actionless]

also please check if setting sudoloopinterval = 60 (or bigger) in /.confg/pikaur.conf makes any difference

[wangqr]

please run pikaur with --debug flag and hit Ctrl+C while it happens to see the stack trace

Traceback (most recent call last):
  File "/usr/sbin/pikaur", line 9, in <module>
    main()
  File "/usr/lib/python3.7/site-packages/pikaur/main.py", line 328, in main
    cli_entry_point()
  File "/usr/lib/python3.7/site-packages/pikaur/main.py", line 238, in cli_entry_point
    run_with_sudo_loop(pikaur_operation)
  File "/usr/lib/python3.7/site-packages/pikaur/core.py", line 251, in run_with_sudo_loop
    result = main_thread.get()
  File "/usr/lib/python3.7/multiprocessing/pool.py", line 677, in get
    self.wait(timeout)
  File "/usr/lib/python3.7/multiprocessing/pool.py", line 674, in wait
    self._event.wait(timeout)
  File "/usr/lib/python3.7/threading.py", line 552, in wait
    signaled = self._cond.wait(timeout)
  File "/usr/lib/python3.7/threading.py", line 296, in wait
    waiter.acquire()
KeyboardInterrupt

also please check if setting sudoloopinterval = 60 (or bigger) in /.confg/pikaur.conf makes any difference

Yes, this solves the issue.

[actionless]

so, either threadlock implementation or sudo -v is buggy under windows (unless you can't reproduce it somewhere else)

just from the information you provided -- the first is more possible

[wangqr]

If I take the 2 functions out (see this gist), the CPU usage is normal (nearly 0)

[actionless]

Is there any difference if you replace sleep to something what will be actually executing in that thread, for example print smth each second?

…

On Fri, 30 Nov 2018 at 19:58, wangqr ***@***.***> wrote: If I take the 2 functions out (see this gist <https://gist.github.com/wangqr/76752502264b371befa763fb173608ba>), the CPU usage is normal (nearly 0) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#317 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABlDdVIjJBVGvv-UM_WW9oT3dBaNV4wLks5u0X--gaJpZM4Y62Ro> .

[wangqr]

I tried various functions. I found that this issue can be reproduced with this example on my computer.

[actionless]

in pikaur/install_info_fetcher.py there is _get_repo_pkgs_info() method which is using ThreadPool

i have an idea what in your environment nested ThreadPool could behave differently

in order to debug this please try:

1. commenting out that method (ie adding return [] at the first line of it), so ThreadPool won't be initiated
2. at the end of with ThreadPool block to call pool.terminate()

[wangqr]

1. commenting out that method (ie adding return [] at the first line of it), so ThreadPool won't be initiated

No, this doesn't make any difference.
I updated the above gist. It seems that pyalpm is causing this issue.

[actionless]

if debugging with gdb also fails in a same way as strace?

[actionless]

if you don't mind i am closing this since the issue is also reproducible with gzip