mitmdump stdout never reaches parent process #6757

Prinzhorn · 2024-03-26T14:25:12Z

Problem Description

I'm spawning mitmdump from Node.js as a child process. Starting with mitmdump 8 stdout never reaches the parent. Only when I kill the mitmdump process will I finally get its output.

Steps to reproduce the behavior:

index.mjs

import { spawn } from 'child_process';

const mitm = spawn(
  '/home/alex/Downloads/mitmproxy-10.2.4-linux-x86_64/mitmdump',
  // '/home/alex/Downloads/mitmproxy-9.0.1-linux/mitmdump',
  // '/home/alex/Downloads/mitmproxy-8.1.1-linux/mitmdump',
  // '/home/alex/Downloads/mitmproxy-7.0.4-linux/mitmdump',
  // '/home/alex/Downloads/mitmproxy-6.0.2-linux/mitmdump',
  // '/home/alex/forks/mitmproxy/venv/bin/mitmdump',
  {
    env: {
      // This has an effect on the venv but not the PyInstaller binary > 7
      PYTHONUNBUFFERED: '1',
    },
  },
);

mitm.stdout.on('data', (data) => {
  console.group(`mitm stdout`);
  console.log(`${data}`);
  console.groupEnd();
});

mitm.stderr.on('data', (data) => {
  console.group(`mitm stderr`);
  console.log(`${data}`);
  console.groupEnd();
});

mitm.on('exit', (code, signal) => {
  console.log(`mitm process exited with code ${code} from signal ${signal}`);
});

node index.mjs
nothingness
killall mitmdump
Now Node.js gets the output

Version 6 + 7: I get stdout
Version 8 + 9 + 10: I don't get stdout, only after I kill the mitmdump process

I assume it must be PyInstaller, because spawning directly from venv/bin works too (but only with PYTHONUNBUFFERED=1). However, if I add the following addon I get all stdout:

import sys


def running():
    print("running")
    sys.stdout.flush()

So I assume PyInstaller does not implement/respect PYTHONUNBUFFERED and mitmproxy does not explicitly flush.

Looking at the PyInstaller issue tracker I assume I must be the first human to spawn a PyInstaller process? Or maybe it's how we use PyInstaller and we can actually configure this on our end?

The text was updated successfully, but these errors were encountered:

Prinzhorn · 2024-03-26T14:28:59Z

It's also interesting that the Python docs regarding PYTHONUNBUFFERED say

Changed in version 3.7: The text layer of the stdout and stderr streams now is unbuffered.

Aren't we using "the text layer"?

Prinzhorn · 2024-03-27T07:16:57Z

It behaves the same with the this ChatGTP Python parent process (just to rule out funny Node.js things):

import subprocess


def run_command(command):
    try:
        process = subprocess.Popen(
            command,
            stdout=subprocess.PIPE,
            stderr=subprocess.PIPE,
            shell=True,
            env=dict(PYTHONUNBUFFERED="1"),
        )

        while True:
            stdout_line = process.stdout.readline().decode().strip()

            if stdout_line:
                print("stdout:", stdout_line)

            # Check if both pipes are closed and process has terminated
            if not stdout_line and process.poll() is not None:
                break

    except Exception as e:
        print("Error:", e)


command = "/home/alex/Downloads/mitmproxy-10.2.4-linux-x86_64/mitmdump"
# command = "/home/alex/Downloads/mitmproxy-9.0.1-linux/mitmdump"
# command = "/home/alex/Downloads/mitmproxy-8.1.1-linux/mitmdump"
# command = "/home/alex/Downloads/mitmproxy-7.0.4-linux/mitmdump"
# command = "/home/alex/Downloads/mitmproxy-6.0.2-linux/mitmdump"
# command = "/home/alex/forks/mitmproxy/venv/bin/mitmdump"

run_command(command)

clearedTakeoff · 2024-04-06T08:23:50Z

I don't have a solution but I thought I'd just add my 2 cents since I recently encountered a similar issue when writing a NodeJS script.

My first attempt was also setting PYTHONBUFFERED variable but it made no difference. What I ended up doing was running mitmdump with a script so the whole command would be /usr/bin/script /path/to/mitmdump. I'm not knowledgeable enough to explain but this somehow "unbuffers" the stream and also makes it accessible using stdout listener.

Obviously it's a dirty hack (and also not portable) but if someone needs a quick workaround on a system that has access to script binary it does the job

Prinzhorn · 2024-04-06T09:22:54Z

Thank you for your input! I think the reason it works is because from what I understand script simulates a tty and as such the child process behaves differently (when you run mitmdump in a terminal you also instantly see the output).

and also not portable

That would be my main problem with it.

I assume you could achieve similar things using https://github.com/microsoft/node-pty, but I would rather not go that route and add yet another layer that can break.

abbbe · 2024-04-09T13:50:31Z

Are you sure you set PYTHONUNBUFFERED correctly?
I have tested it using 'ssh -T' to spawn a process without pty.

Without PYTHONUNBUFFERED stdout is indeed buffered:

abb@ape t1s3 % ssh -T kali1 "set -x; tty; mitmdump > /tmp/log &; sleep 1; ls -l /tmp/log; killall mitmdump; sleep 1; ls -l /tmp/log"
+zsh:1> tty
not a tty
+zsh:1> mitmdump
+zsh:1> sleep 1
-rw-r--r-- 1 abb abb 0 Apr  9 15:45 /tmp/log
+zsh:1> ls -l /tmp/log
+zsh:1> killall mitmdump
+zsh:1> sleep 1
+zsh:1> ls -l /tmp/log
-rw-r--r-- 1 abb abb 50 Apr  9 15:45 /tmp/log

But with PYTHONUNBUFFERED stdout seems to be flushed ok:

abb@ape t1s3 % ssh -T kali1 "set -x; tty; PYTHONUNBUFFERED=1 mitmdump > /tmp/log &; sleep 1; ls -l /tmp/log; killall mitmdump; sleep 1; ls -l /tmp/log"

+zsh:1> tty
not a tty
+zsh:1> PYTHONUNBUFFERED=1 mitmdump
+zsh:1> sleep 1
+zsh:1> ls -l /tmp/log
-rw-r--r-- 1 abb abb 50 Apr  9 15:47 /tmp/log
+zsh:1> killall mitmdump
+zsh:1> sleep 1
+zsh:1> ls -l /tmp/log
-rw-r--r-- 1 abb abb 50 Apr  9 15:47 /tmp/log

I have tested on Kali linux with python3 & mitmproxy from packages:

abb@kali1:~$ uname -a
Linux kali1 6.3.0-kali1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.3.7-1kali1 (2023-06-29) x86_64 GNU/Linux

abb@kali1:~$ mitmdump --version
Mitmproxy: 9.0.1
Python:    3.11.4
OpenSSL:   OpenSSL 3.0.10 1 Aug 2023
Platform:  Linux-6.3.0-kali1-amd64-x86_64-with-glibc2.37

And with latest version of mitmproxy installed with pip in a virtualenv, it behaves the same.

$ mitmproxy --version
Mitmproxy: 10.2.4
Python:    3.11.8
OpenSSL:   OpenSSL 3.2.1 30 Jan 2024
Platform:  Linux-6.3.0-kali1-amd64-x86_64-with-glibc2.37

Prinzhorn · 2024-04-09T17:25:26Z

Are you sure you set PYTHONUNBUFFERED correctly?

I've provided both a Node.js and Python script, I guess I'm setting it correctly in there? Since PYTHONUNBUFFERED affects the venv but not the PyInstaller binary I must be setting it correctly, or else why would the behavior change? Could you test one of the scripts locally as well? I'm not sure if what you're doing with ssh -T is an accurate representation of what I'm doing.

abbbe · 2024-04-09T17:43:43Z

I am not an expert on nodejs… Just offered some observations regarding stdout buffering behaviour of mitmproxy without pty but with PYTHONUNBUFFERED=1. As far as I can tell it behaves as expected.

Maybe you should spawn /usr/bin/env instead of mitmproxy and assess its output to see if env gets set as expected.

abbbe · 2024-04-09T17:45:24Z

I will try your python test script later

abbbe · 2024-04-09T17:46:14Z

What OS do you use?

Prinzhorn · 2024-04-09T18:28:42Z

Ubuntu 23.10. So I'd assume Kali should behave the same.

abbbe · 2024-04-09T19:55:10Z

Your python script invoking mitmproxy works, it captures stdout of mitmdump on my kali.
Not sure what goes wrong on your end... maybe it fails to execute mitmproxy due to wrong path, file permissions, missing dependencies, etc. Try capturing stderr, try strace'ing it, etc.
At any rate it is not mitmproxy nor python output buffering issue.
Good luck.

clearedTakeoff · 2024-04-10T11:03:32Z

I can't reproduce these results at all using ssh -T when I'm sshing into a machine using Mint 21.1 so something must be different on Kali then?

tty
not a tty
mitmdump > /tmp/log &
sleep 2
ls -l /tmp/log
-rw-rw-r-- 1 user user 0 Apr 10 12:54 /tmp/log
killall mitmdump
sleep 2
ls -l /tmp/log
-rw-rw-r-- 1 user user 50 Apr 10 12:55 /tmp/log

And then the same thing using PYTHONUNBUFFERED

tty
not a tty
PYTHONUNBUFFERED=1 mitmdump > /tmp/log &
sleep 2
ls -l /tmp/log
-rw-rw-r-- 1 user user 0 Apr 10 12:56 /tmp/log
sleep 2
ls -l /tmp/log
-rw-rw-r-- 1 user user 0 Apr 10 12:56 /tmp/log
killall mitmdump
ls -l /tmp/log
-rw-rw-r-- 1 user user 50 Apr 10 12:57 /tmp/log

I am using bash though not zsh

abbbe · 2024-04-10T11:13:02Z

strange. well, maybe try bash. and try getting yourself Kali VM.

clearedTakeoff · 2024-04-10T11:48:20Z

Honestly no idea what's going on but even on fresh Kali VM I'm getting the same results

└─$ uname -a
Linux kali 6.6.9-amd64 #1 SMP PREEMPT_DYNAMIC Kali 6.6.9-1kali1 (2024-01-08) x86_64 GNU/Linux

And then running the same command with PYTHONUNBUFFERED. I only increased sleep length to be safe and make sure I'm not reading file too fast.

user@MACHINE:~$ ssh -p 3022 -T kali@localhost "set -x; tty; PYTHONUNBUFFERED=1 mitmdump > /tmp/log &; sleep 5; ls -l /tmp/log; killall mitmdump; sleep 1; ls -l /tmp/log"
kali@localhost's password: 
+zsh:1> tty
not a tty
+zsh:1> PYTHONUNBUFFERED=1 mitmdump
+zsh:1> sleep 5
+zsh:1> ls -l /tmp/log
-rw-r--r-- 1 kali kali 0 Apr 10 07:43 /tmp/log
+zsh:1> killall mitmdump
+zsh:1> sleep 1
+zsh:1> ls -l /tmp/log
-rw-r--r-- 1 kali kali 50 Apr 10 07:43 /tmp/log

abbbe · 2024-04-10T11:55:15Z

Curious ;)

I still get the same results as yesterday.

abb@ape ~ % ssh -T kali1 "set -x; tty; PYTHONUNBUFFERED=1 /tmp/venv/bin/mitmdump > /tmp/log &; sleep 5; ls -l /tmp/log; killall mitmdump; sleep 1; ls -l /tmp/log"
+zsh:1> tty
not a tty
+zsh:1> PYTHONUNBUFFERED=1 /tmp/venv/bin/mitmdump
+zsh:1> sleep 5
-rw-r--r-- 1 abb abb 50 Apr 10 13:53 /tmp/log
+zsh:1> ls -l /tmp/log
+zsh:1> killall mitmdump
+zsh:1> sleep 1
-rw-r--r-- 1 abb abb 50 Apr 10 13:53 /tmp/log
+zsh:1> ls -l /tmp/log

abb@ape ~ % ssh -T kali1 "uname -a; /tmp/venv/bin/mitmproxy --version"
Linux kali1 6.3.0-kali1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.3.7-1kali1 (2023-06-29) x86_64 GNU/Linux
Mitmproxy: 10.2.4
Python:    3.11.8
OpenSSL:   OpenSSL 3.2.1 30 Jan 2024
Platform:  Linux-6.3.0-kali1-amd64-x86_64-with-glibc2.37

My kali is much older. Can you point me to the exact Kali you've downloaded? I get myself fresh one too.

clearedTakeoff · 2024-04-10T11:58:08Z

I got the VirtualBox image on this page https://www.kali.org/get-kali/#kali-virtual-machines. Version is kali-2024.1

abbbe · 2024-04-10T12:16:47Z

I don't have VirtualBox, installed a fresh on ProxMox. Still works for me:

abb@ape ~ % ssh -T kali3 "set -x; tty; PYTHONUNBUFFERED=1 mitmdump > /tmp/log &; sleep 5; ls -l /tmp/log; killall mitmdump; sleep 1; ls -l /tmp/log"
+zsh:1> tty
not a tty
+zsh:1> PYTHONUNBUFFERED=1 mitmdump
+zsh:1> sleep 5
+zsh:1> ls -l /tmp/log
-rw-r--r-- 1 kali kali 50 Apr 10 08:13 /tmp/log
+zsh:1> killall mitmdump
+zsh:1> sleep 1
+zsh:1> ls -l /tmp/log
-rw-r--r-- 1 kali kali 50 Apr 10 08:13 /tmp/log

Can you dump all including env vars in one go?

abb@ape ~ % ssh -T kali3 "uname -a; mitmproxy --version; env"
Linux kali 6.6.9-amd64 #1 SMP PREEMPT_DYNAMIC Kali 6.6.9-1kali1 (2024-01-08) x86_64 GNU/Linux
Mitmproxy: 10.2.3
Python:    3.11.8
OpenSSL:   OpenSSL 3.1.5 30 Jan 2024
Platform:  Linux-6.6.9-amd64-x86_64-with-glibc2.37
LC_TERMINAL_VERSION=3.4.15
LC_CTYPE=UTF-8
LC_TERMINAL=iTerm2
USER=kali
LOGNAME=kali
HOME=/home/kali
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games
SHELL=/usr/bin/zsh
XDG_SESSION_ID=15
XDG_RUNTIME_DIR=/run/user/1000
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
XDG_SESSION_TYPE=tty
XDG_SESSION_CLASS=user
MOTD_SHOWN=pam
COMMAND_NOT_FOUND_INSTALL_PROMPT=1
POWERSHELL_UPDATECHECK=Off
POWERSHELL_TELEMETRY_OPTOUT=1
DOTNET_CLI_TELEMETRY_OPTOUT=1
LANG=en_US.UTF-8
SSH_CLIENT=192.168.33.34 57571 22
SSH_CONNECTION=192.168.33.34 57571 192.168.33.121 22
SHLVL=0
PWD=/home/kali
OLDPWD=/home/kali
_=/usr/bin/env

clearedTakeoff · 2024-04-10T12:28:39Z

$ ssh -p 3022 -T kali@localhost "uname -a; mitmproxy --version; env"
kali@localhost's password: 
Linux kali 6.6.9-amd64 #1 SMP PREEMPT_DYNAMIC Kali 6.6.9-1kali1 (2024-01-08) x86_64 GNU/Linux
Mitmproxy: 10.2.2
Python:    3.11.8
OpenSSL:   OpenSSL 3.1.4 24 Oct 2023
Platform:  Linux-6.6.9-amd64-x86_64-with-glibc2.37
LC_ADDRESS=sl_SI.UTF-8
LC_NAME=sl_SI.UTF-8
LC_MONETARY=sl_SI.UTF-8
LC_PAPER=sl_SI.UTF-8
LANG=en_US.UTF-8
LC_IDENTIFICATION=sl_SI.UTF-8
LC_TELEPHONE=sl_SI.UTF-8
LC_MEASUREMENT=sl_SI.UTF-8
LC_NUMERIC=sl_SI.UTF-8
USER=kali
LOGNAME=kali
HOME=/home/kali
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games
SHELL=/usr/bin/zsh
XDG_SESSION_ID=5
XDG_RUNTIME_DIR=/run/user/1000
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
XDG_SESSION_TYPE=tty
XDG_SESSION_CLASS=user
MOTD_SHOWN=pam
COMMAND_NOT_FOUND_INSTALL_PROMPT=1
POWERSHELL_UPDATECHECK=Off
POWERSHELL_TELEMETRY_OPTOUT=1
DOTNET_CLI_TELEMETRY_OPTOUT=1
SSH_CLIENT=10.0.2.2 54636 22
SSH_CONNECTION=10.0.2.2 54636 10.0.2.15 22
SHLVL=0
PWD=/home/kali
OLDPWD=/home/kali
_=/usr/bin/env

This is using system's mitmproxy but I also tested it with latest mitmdump (10.2.4)

abbbe · 2024-04-10T12:42:48Z

Well, there are still differences between our systems still, but nothing major:

abb@ape ~ % diff -u /tmp/abb /tmp/cto
--- /tmp/abb	2024-04-10 14:30:29
+++ /tmp/cto	2024-04-10 14:30:12
@@ -1,17 +1,23 @@
 Linux kali 6.6.9-amd64 #1 SMP PREEMPT_DYNAMIC Kali 6.6.9-1kali1 (2024-01-08) x86_64 GNU/Linux
-Mitmproxy: 10.2.3
+Mitmproxy: 10.2.2
 Python:    3.11.8
-OpenSSL:   OpenSSL 3.1.5 30 Jan 2024
+OpenSSL:   OpenSSL 3.1.4 24 Oct 2023
 Platform:  Linux-6.6.9-amd64-x86_64-with-glibc2.37
-LC_TERMINAL_VERSION=3.4.15
-LC_CTYPE=UTF-8
-LC_TERMINAL=iTerm2
+LC_ADDRESS=sl_SI.UTF-8
+LC_NAME=sl_SI.UTF-8
+LC_MONETARY=sl_SI.UTF-8
+LC_PAPER=sl_SI.UTF-8
+LANG=en_US.UTF-8
+LC_IDENTIFICATION=sl_SI.UTF-8
+LC_TELEPHONE=sl_SI.UTF-8
+LC_MEASUREMENT=sl_SI.UTF-8
+LC_NUMERIC=sl_SI.UTF-8
 USER=kali
 LOGNAME=kali
 HOME=/home/kali
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games
 SHELL=/usr/bin/zsh
-XDG_SESSION_ID=21
+XDG_SESSION_ID=5
 XDG_RUNTIME_DIR=/run/user/1000
 DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
 XDG_SESSION_TYPE=tty
@@ -21,9 +27,8 @@
 POWERSHELL_UPDATECHECK=Off
 POWERSHELL_TELEMETRY_OPTOUT=1
 DOTNET_CLI_TELEMETRY_OPTOUT=1
-LANG=en_US.UTF-8
-SSH_CLIENT=192.168.33.34 58546 22
-SSH_CONNECTION=192.168.33.34 58546 192.168.33.121 22
+SSH_CLIENT=10.0.2.2 54636 22
+SSH_CONNECTION=10.0.2.2 54636 10.0.2.15 22
 SHLVL=0
 PWD=/home/kali
 OLDPWD=/home/kali

We are likely to use different SSH clients, let's take those out of the equation. Make test.sh script on kali and run it via ssh localhost launched from the graphical console directly, like this:

If you still get different results, I suggest maybe you get yourself the exact same image as I did https://kali.download/base-images/kali-weekly/kali-linux-2024-W15-qemu-amd64.7z (SHA1 5dd0c36fd089ecd217432992a3bd13dacdc88f07).

clearedTakeoff · 2024-04-10T13:23:58Z

Ok now I'm finally at a point where I can reproduce your results :). So PYTHONUNBUFFERED with mitmdump didn't work properly for me on kali-2024.1 but it does work on the latest weekly build which you linked: kali-linux-2024-W15.

Prinzhorn · 2024-04-10T16:10:48Z

Thank you two for looking into this! It became a little hard to follow, can you confirm that you are both working with the latest mitmproxy downloaded from https://mitmproxy.org/downloads/#10.2.4/ ? Because I don't know how exactly Kali packages mitmproxy (https://gitlab.com/kalilinux/packages/mitmproxy) and if they are using PyInstaller at all. Juding from issues such as https://bugs.kali.org/view.php?id=8695 I don't think they are, so it's closer to running the venv (which respects PYTHONUNBUFFERED in my tests).

clearedTakeoff · 2024-04-10T16:43:12Z

Sorry I didn't even realize there might be a difference so all this testing was kind of pointless 😬 What I did was tested on kali-2024.1 with binary downloaded from official site (which didn't unbuffer the output). Then I was lazy and used the system binary (where output was correctly unbuffered) on the weekly build.

@Prinzhorn Your assumption seems to be correct. I rechecked both Kali builds again and in both of them PYTHONUNBUFFERED makes no difference if used with downloaded binaries, output only gets flushed once the process is terminated. If I use packaged mitmdump provided with OS then it PYTHONUNBUFFERED works fine.

Prinzhorn · 2024-04-10T17:21:46Z

Nice, thanks for confirming! Now I guess all we need is a minimal repro to get this fixed in PyInstaller (I didn't find anything related in their issue tracker). I gave up setting up PyInstaller locally, but if it doesn't conflict with your system (on Ubuntu none of the suggested ways to install made it run successfully) then this should be enough to produce a minimal binary:

hello.py (via ChatGPT)

import time

def main():
    while True:
        print("Hello, world! Press Ctrl+C to exit.")
        time.sleep(1)

if __name__ == "__main__":
    main()

pyinstaller --onefile hello.py
./dist/hello

Now if this hello binary behaves the same, it's definitely not an issue with mitmproxy itself or how we're using PyInstaller.

clearedTakeoff · 2024-04-10T19:27:22Z

I took a shot at testing this and I'm getting mixed results. Here's the pyinstaller version I used for reference

414 INFO: PyInstaller: 6.5.0, contrib hooks: 2024.3
414 INFO: Python: 3.11.8
415 INFO: Platform: Linux-6.6.9-amd64-x86_64-with-glibc2.37

Now for the weird part: if I run the binary (with redirected output) and then kill it with SIGTERM or SIGKILL it doesn't flush anything at all. The only way I'm able to get it to flush things is when terminating it with SIGINT. This makes me think I'm doing something wrong but I'm not sure what?

I've been able to kind of reproduce the mitmdump behavior. Excuse the long shell one-liner but as soon as I put this into a script file and run it, I can't get it to flush any output no matter how I kill it.

$ ./dist/hello > /tmp/log 2> /dev/null &; HPID=$!; sleep 5; ls -l /tmp/log; kill -s SIGINT $HPID; ls -l /tmp/log
[1] 16000
-rw-r--r-- 1 kali kali 0 Apr 10 15:14 /tmp/log
-rw-r--r-- 1 kali kali 45 Apr 10 15:14 /tmp/log
                                                                                                                                                                                                                       
[1]  + exit 1     ./dist/hello > /tmp/log 2> /dev/null

Again adding PYTHONUNBUFFERED doesn't do anything

$ PYTHONUNBUFFERED=1 ./dist/hello > /tmp/log 2> /dev/null &; HPID=$!; sleep 5; ls -l /tmp/log; kill -s SIGINT $HPID; ls -l /tmp/log
[1] 18077
-rw-r--r-- 1 kali kali 0 Apr 10 15:19 /tmp/log
-rw-r--r-- 1 kali kali 45 Apr 10 15:19 /tmp/log
                                                                                                                                                                                                                       
[1]  + exit 1     PYTHONUNBUFFERED=1 ./dist/hello > /tmp/log 2> /dev/null

I know this is a bit all over the place but hopefully someone more knowledgeable can provide some insight into what's happening.

Prinzhorn · 2024-04-25T17:19:11Z

Looks like we can configure this in the PyInstaller spec #6821

In the end it's a tiny change, thanks for helping me figure this out!

Prinzhorn added the kind/triage Unclassified issues label Mar 26, 2024

Prinzhorn mentioned this issue Apr 24, 2024

Packaged binaries do not respect PYTHONUNBUFFERED and parent process never gets stdout / stderr pyinstaller/pyinstaller#8426

Closed

6 tasks

Prinzhorn mentioned this issue Apr 25, 2024

Update PyInstaller spec to set the u (unbuffered) flag #6821

Merged

3 tasks

Prinzhorn closed this as completed in #6821 Apr 28, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

mitmdump stdout never reaches parent process #6757

mitmdump stdout never reaches parent process #6757

Prinzhorn commented Mar 26, 2024 •

edited

Prinzhorn commented Mar 26, 2024

Prinzhorn commented Mar 27, 2024 •

edited

clearedTakeoff commented Apr 6, 2024 •

edited

Prinzhorn commented Apr 6, 2024 •

edited

abbbe commented Apr 9, 2024

Prinzhorn commented Apr 9, 2024

abbbe commented Apr 9, 2024

abbbe commented Apr 9, 2024

abbbe commented Apr 9, 2024

Prinzhorn commented Apr 9, 2024

abbbe commented Apr 9, 2024

clearedTakeoff commented Apr 10, 2024 •

edited

abbbe commented Apr 10, 2024

clearedTakeoff commented Apr 10, 2024

abbbe commented Apr 10, 2024

clearedTakeoff commented Apr 10, 2024

abbbe commented Apr 10, 2024

clearedTakeoff commented Apr 10, 2024

abbbe commented Apr 10, 2024

clearedTakeoff commented Apr 10, 2024

Prinzhorn commented Apr 10, 2024

clearedTakeoff commented Apr 10, 2024

Prinzhorn commented Apr 10, 2024

clearedTakeoff commented Apr 10, 2024

Prinzhorn commented Apr 25, 2024 •

edited

mitmdump stdout never reaches parent process #6757

mitmdump stdout never reaches parent process #6757

Comments

Prinzhorn commented Mar 26, 2024 • edited

Problem Description

Steps to reproduce the behavior:

Prinzhorn commented Mar 26, 2024

Prinzhorn commented Mar 27, 2024 • edited

clearedTakeoff commented Apr 6, 2024 • edited

Prinzhorn commented Apr 6, 2024 • edited

abbbe commented Apr 9, 2024

Prinzhorn commented Apr 9, 2024

abbbe commented Apr 9, 2024

abbbe commented Apr 9, 2024

abbbe commented Apr 9, 2024

Prinzhorn commented Apr 9, 2024

abbbe commented Apr 9, 2024

clearedTakeoff commented Apr 10, 2024 • edited

abbbe commented Apr 10, 2024

clearedTakeoff commented Apr 10, 2024

abbbe commented Apr 10, 2024

clearedTakeoff commented Apr 10, 2024

abbbe commented Apr 10, 2024

clearedTakeoff commented Apr 10, 2024

abbbe commented Apr 10, 2024

clearedTakeoff commented Apr 10, 2024

Prinzhorn commented Apr 10, 2024

clearedTakeoff commented Apr 10, 2024

Prinzhorn commented Apr 10, 2024

clearedTakeoff commented Apr 10, 2024

Prinzhorn commented Apr 25, 2024 • edited

Prinzhorn commented Mar 26, 2024 •

edited

Prinzhorn commented Mar 27, 2024 •

edited

clearedTakeoff commented Apr 6, 2024 •

edited

Prinzhorn commented Apr 6, 2024 •

edited

clearedTakeoff commented Apr 10, 2024 •

edited

Prinzhorn commented Apr 25, 2024 •

edited