Mitmproxy taking long time to respond on Macbook M1 Sonoma about mitmproxy HOT 11 OPEN

All the commands you mentioned work instantaneously for me on the following system:

Mitmproxy: 11.0.0.dev (+10, commit f05c050)
Python:    3.12.1
OpenSSL:   OpenSSL 3.1.4 24 Oct 2023
Platform:  macOS-14.4.1-arm64-arm-64bit

from mitmproxy.

I also ran into a similar issue on my Macbook M1.

The Mitmproxy version I am running is 10.1.4. Is it fixed in later versions?

from mitmproxy.

I would recommend to update to the latest release anyhow. :)

from mitmproxy.

@mhils can you test the same on 10.3.0 version as well since its the latest version available online in pip. The issue I am facing looks similar to #6474

from mitmproxy.

#6474 is a complete freeze of the application, which seems unrelated.

from mitmproxy.

@mhils I upgraded to 10.3.0 that is the latest available version online. The proxy worked fine last night but the response times today morning are ~5 minutes or it times out depending on the website.

curl -x localhost:8080 -k https://www.google.com ---- 4 minutes
curl -x localhost:8080 -k https://www.facebook.com ---- 4 minutes
curl -x localhost:8080 -k https://www.yahoo.com ---- curl: (28) Proxy CONNECT aborted due to timeout

I tried to see the error in the logs by using mitmdump -v but didn't see much except connect/disconnect and response statements.

Can you please help?

from mitmproxy.

I don't have capacity at the moment, sorry. This needs a good reproducer in the first place, otherwise it's not really actionable.

from mitmproxy.

Sure. If there are any mitmproxy logs beyond mitmdump we can use for troubleshooting, please let us know.

from mitmproxy.

It may be useful to send SIGUSR1 / SIGUSR2 signals to a running mitmproxy instance that exhibits that behavior to see if anything sticks out.

from mitmproxy.

I just sent SIGUSR1 and SIGUSR2 signals to mitmproxy. Links to the logs are below:-

https://gist.github.com/vineet1984/3db14195b78a6a83f15b7d0bb2a2c2b0
https://gist.github.com/vineet1984/62d8422053bea9cc473a4618d69ad89c

From what I can see, there is a line "work_item = work_queue.get(block=True)" in SIGUSR2 logs that could be a possible glitch. Do you see any other glaring issue?

from mitmproxy.

This all looks good - I'm wondering what kind of output you'd get here during one of these super slow requests?

from mitmproxy.