Werkzeug: 閉じたパイプに書き込んだ後、Werkzeugがクラッシュする

Werkzeug開発サーバーではなく、GunicornやuWSGIなどの本番WSGIサーバーを使用します。

開発にWerkzeug開発サーバー（つまり、AFAICT、その使用目的）を使用していること、つまりブラウザーをポート5000に直接接続していることを除いて、非常によく似た問題があります。

エラーは1時間に数回発生し、サーバーを手動で再起動して開発を継続する必要があります。

トレースバックは次のとおりです。

Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 801, in __bootstrap_inner
    self.run()
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 754, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/Users/fermigier/envs/extranet-spr/lib/python2.7/site-packages/werkzeug/serving.py", line 659, in inner
    srv.serve_forever()
  File "/Users/fermigier/envs/extranet-spr/lib/python2.7/site-packages/werkzeug/serving.py", line 499, in serve_forever
    HTTPServer.serve_forever(self)
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 238, in serve_forever
    self._handle_request_noblock()
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 297, in _handle_request_noblock
    self.handle_error(request, client_address)
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 295, in _handle_request_noblock
    self.process_request(request, client_address)
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 321, in process_request
    self.finish_request(request, client_address)
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 334, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 655, in __init__
    self.handle()
  File "/Users/fermigier/envs/extranet-spr/lib/python2.7/site-packages/werkzeug/serving.py", line 216, in handle
    rv = BaseHTTPRequestHandler.handle(self)
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/BaseHTTPServer.py", line 340, in handle
    self.handle_one_request()
  File "/Users/fermigier/envs/extranet-spr/lib/python2.7/site-packages/werkzeug/serving.py", line 251, in handle_one_request
    return self.run_wsgi()
  File "/Users/fermigier/envs/extranet-spr/lib/python2.7/site-packages/werkzeug/serving.py", line 193, in run_wsgi
    execute(self.server.app)
  File "/Users/fermigier/envs/extranet-spr/lib/python2.7/site-packages/werkzeug/serving.py", line 186, in execute
    write(b'')
  File "/Users/fermigier/envs/extranet-spr/lib/python2.7/site-packages/werkzeug/serving.py", line 152, in write
    self.send_header(key, value)
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/BaseHTTPServer.py", line 401, in send_header
    self.wfile.write("%s: %s\r\n" % (keyword, value))
IOError: [Errno 32] Broken pipe

開発サーバー（ debug=True ）で@sfermigierとまったく同じ問題が

この動作は通常、非常に単純なケースで発生します。ある種のオートコンプリート機能を使用しています。 ブラウザはクエリトークンの接続を開始してから、さらにトークンの別のリクエストを停止して開始します。 あなたはたくさんの壊れたパイプになってしまうでしょう。 そして、これは開発サーバーを完全にブロックする
したがって、フル機能のアプリケーションサーバーを使用することを提案することは良い回避策ですが、それでもここで問題が発生します。 もちろん開発のみの問題ですが、トリガーするのが非常に一般的であるという事実は、_プロトコル内部_に慣れていない多くの開発者にとっては邪魔になります。
壊れたパイプは非常に一般的であり（エラーによる長いリクエストと開発者がブラウザの停止ボタンを押すことを考えてください）、開発サーバーを壊してはなりません。
ただ私の意見です。 :)

@xcash

この動作は通常、非常に単純なケースで発生します。ある種のオートコンプリート機能を使用しています。 ブラウザはクエリトークンの接続を開始してから、さらにトークンの別のリクエストを停止して開始します。

関連している場合は、 browsersyncとgulp.jsを使用して、この問題が発生していることを確認できます。

WSGIサーバーの実行を含まないソリューションを持っている人はいますか？ ボットがホストに対してSYNスキャンを実行すると、この問題が発生しているようです。

@glennzw環境をより具体的にすることはできますか？ ボットがアクセスできるオープンWeb上で開発サーバーを公開しないでください。 :)このような状況では、クライアントのデモホストのように、少なくともフットプリントが非常に小さいgunicornのような実際のアプリケーションサーバーを使用することをお勧めします。

FWIW、私はリリースにあまり追いついておらず、この（非常に厄介な）問題が2016年5月から8月の間に発生し始めました。 私はこれをsetup.py install_requires = ['Werkzeug<0.11', 'flask<0.11', ...に追加しました-これは問題を回避しているようです（IME、Werkzeugをピン留めするだけではうまくいかなかったようです？）

私にとって、複製のケースは非常に単純でした。ページをロードしますが、ロードを終了させないでください。 つまり、パイプの破損エラーをトリガーするだけで、ウェブサーバーがクラッシュし、他のリクエストの処理に失敗します。 私見ですが、クライアントが接続を途中で閉じた場合、Webサーバーは_フォールオーバー_できません。開発接続であってもです。

passthrough_errorsがどこかに設定されているということでしょうか？

その場合の@untitaker 、パレット/フラスコ＃1674パレット/フラスコ＃1679パレット/フラスコ＃1928はおそらく関連していますか？

わからない、記者の一人に確認してもらいたい。

2016年8月26日17時〇五分25秒CESTでは、デイビット・ロードの[email protected]は書きました：

その場合は@untitaker 、パレット/フラスコ＃1674パレット/フラスコ＃1679
パレット/フラスコ＃1928はおそらく関連していますか？

あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください。
https://github.com/pallets/werkzeug/issues/954#issuecomment -242761250

K-9Mailを使用してAndroidデバイスから送信されました。 簡潔に申し訳ありません。

cc @miguelgrinberg

Werkzeugは壊れたパイプと接続のリセットエラーを処理する必要があると思います。 これらは実際にはエラーを示すものではなく、クライアントはただ立ち去っただけです。 この場合、特別な例外を発生させる必要があるようです。エラーパススルーが設定されている場合でも、上記のキャッチオールによって無視される例外として認識されます。

gunicornの機能は次のとおりです： https ：

それがやるべきことです。 私は再現する方法を理解しようとしています
この動作ですが、利用できる明確なテストケースはまだありません。 したがって、質問
約passthrough_errors 。

これはWerkzeugのバグではなく、ユーザーのブラウザが
（代わりに、他のリクエストをブロックする接続がまだ開いているだけです
サーバーがクラッシュします）。 ブラウザを閉じて再度開くと、サーバーは
再び機能します。

2016年8月26日金曜日11:54:16 AM -0700に、MiguelGrinbergは次のように書いています。

Werkzeugは壊れたパイプと接続のリセットエラーを処理する必要があると思います。 これらは実際にはエラーを示すものではなく、クライアントはただ立ち去っただけです。 この場合、特別な例外を発生させる必要があるようです。エラーパススルーが設定されている場合でも、上記のキャッチオールによって無視される例外として認識されます。

gunicornの機能は次のとおりです： https ：

あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください。
https://github.com/pallets/werkzeug/issues/954#issuecomment -242821084

ああ、壊れたパイプエラーが表示されます、はい、しかしそれらは説明されているようにサーバーをハングアップさせてはいけません。 考えられる理由については、以前のコメントを参照してください。

最新のビットを再度テストしましたが、環境内で同じ動作が見られます。 しかし、あなたは再現に苦労しているようだったので、私はなぜ私が特別なのかを引き出しようとしました。

import time
from flask import Flask
app = Flask(__name__)


@app.route('/')
def hello_world():
    time.sleep(5)
    return 'Hello, World!'


if __name__ == "__main__":
    app.run()

flask run期待どおりに機能しますが、 python hello.py介して開始したときに応答をレンダリングする前に、Webブラウザーを閉じると、Webサーバーがクラッシュします。

応答の一部が失われているようです。

2016年8月26日金曜日12:29:39 PM -0700に、claygは次のように書いています。

最新のビットを再度テストしましたが、環境内で同じ動作が見られます。 しかし、あなたは再現に苦労しているようだったので、私はなぜ私が特別なのかを引き出しようとしました。

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/pallets/werkzeug/issues/954#issuecomment-242829536

はい、スラックトリプルティックでは見積もりをブロックする方法であり、 ctrl-returnは改行する方法です
githubでは、トリプルティックは見積もりをブロックする方法ですが、 ctrl-returnは送信する方法です
...とにかく...筋肉の記憶

投稿を送信した直後に編集して終了しました。メールから返信しているようで、編集後にgithubから別の通知が送信されるかどうかわからないため、返信しています。

上記の@claygによる睡眠テストでは再現できません。 実際、パイプの破損エラーはまったく発生しません。 そのリクエストがレスポンスを返す前にブラウザを閉じましたが、Werkzeugはとにかく最後までリクエストを実行し、コンソールに200ログ行を出力し、エラーを表示しません。

また、ストリーミング応答を使用して終わりのないストリームでビデオフレームを提供するフラスコビデオストリーミングの例を使用して同じトリックを試しました。その場合でも、ブラウザーを閉じることができ、リクエストはエラーなしで終了します。 これは奇妙なことです。過去に、このアプリケーションがリクエストを終了する前にコンソールへのパイプの破損エラーをトリガーすると確信していたからです。

実際、私はあまりにも早く話しました。 Python 2.7を使用すると、ビデオストリーミングアプリで毎回再現できます。 3.5では再現できません。 上記のすべてのスタックトレースは2.7のものであるため、Python 3でテストする場合は、この点に注意してください。

もう1つの興味深いデータポイント。 リローダーを使用して実行している場合、子プロセスが終了すると、リローダーを実行しているマスタープロセスが別のプロセスを開始するため、中断は発生しません。 ただし、リローダーなしでサーバーを実行している場合は、パイプの破損エラーによりコンソールに戻ります。

編集：別のプロセス部分を開始するリローダーを無視します。これは発生していないようで、代わりにパススルーエラー設定を変更した場合の影響が見られた可能性があります。

さて、これが私が起こっていると思うことの分析です：

• クライアントはリクエストの途中で消えます
• リクエストは続行されます。 ソケット接続はバッファリングされているように見えるため、ほとんどの場合、ソケットへの書き込みは問題を引き起こしません。
• リクエストが終了すると、ソケットサーバークラスはソケットにflush()を発行します。 これは、現在修正されているPythonライブラリの古いバグの対象でした： http ： socket.errorをキャッチして無視することでした。
• 次に、ソケットサーバーは接続を閉じようとします。 これは、OPからのバックトレースからの次のスタックフレームです。

File "/usr/lib/python2.7/SocketServer.py", line 710, in finish self.wfile.close()

• 残念ながら、Python 2.7では、 socket.close()メソッドが最初に行うことは再びフラッシュすることです。

File "/usr/lib/python2.7/socket.py", line 279, in close self.flush()

• フラッシュでのこの2回目の試行は、try / exceptionで保護されていないため、EPIPE例外が発生します。
• ソケットサーバーは例外をキャッチし、サーバーのhandle_error()メソッドに配信します。
• handle_error()のWerkzeug実装は、 passthrough_errors設定を確認します。これは、常にTrueに設定されているため、EPIPEエラーを再発生させ、上。

Python 3のソケットコードは完全に異なり、特に、try / exceptsがないとフラッシュ呼び出しがないように見えます。 Python 3を使用している場合、EPIPEエラーはWerkzeugにまでバブルしません。

passthrough_errorsをtrueに設定することもできますか？ Werkzeugでは、デフォルトではfalseです。

2016年8月27日午前2時10分13秒CESTでは、ミゲルGrinbergの[email protected]は書きました：

さて、これが私が起こっていると思うことの分析です：

• クライアントはリクエストの途中で消えます
• リクエストは続行されます。 ソケット接続は
  バッファリングされているため、ほとんどの場合、ソケットへの書き込みは何も引き起こしません
  問題。
• リクエストが終了すると、ソケットサーバークラスはflush()を発行します
  ソケットに。 これはPythonライブラリの古いバグの対象でした
  これは現在修正されています： http ：
  この修正の解決策は、 socket.errorをキャッチして無視することでした。
• 次に、ソケットサーバーは接続を閉じようとします。 これは
  OPからのバックトレースからの次のスタックフレーム：

 File "/usr/lib/python2.7/SocketServer.py", line 710, in finish
 self.wfile.close()

• 残念ながら、Python 2.7では、最初にsocket.close()
  メソッドは再びフラッシュします：

 File "/usr/lib/python2.7/socket.py", line 279, in close
 self.flush()

• フラッシュでのこの2回目の試行は、try / exceptionで保護されていないため、
  EPIPE例外が発生します。
• ソケットサーバーは例外をキャッチし、それをに配信します
  サーバーのhandle_error()メソッド。
• handle_error()のWerkzeug実装は、
  passthrough_errors設定、そしてこれは常に設定されているので
  Trueは、EPIPEエラーを再発生させ、トップに到達させます。

Python 3のソケットコードは完全に異なり、特に、
try / exceptsなしでフラッシュ呼び出しがないようです
彼ら。 EPIPEエラーは、使用時にWerkzeugまでバブルアップしません。
Python3。

あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください。
https://github.com/pallets/werkzeug/issues/954#issuecomment -242881523

K-9Mailを使用してAndroidデバイスから送信されました。 簡潔に申し訳ありません。

ああ、ええと： https ：

passthrough_errorsはapp.debug依存する必要があると思います。 NVM、役に立たない

そのPRを実際に元に戻す以外に選択肢はありません。 passthrough_errors=Trueは、本来の動作を実行するだけです。これは、プログラムにデバッガーを接続していない場合、デフォルトの適切な動作ではありません。

気にしないで、私は別の方法を見つけました。 2つのPR：

• https://github.com/pallets/flask/pull/1996-トレースバックがまだ表示されていることを除いて、これはそれ自体で問題を修正します
• https://github.com/pallets/werkzeug/pull/998-$＃$ passthrough_errors=Trueであっても、ソケットエラーを再発生させないでください。 とにかく意図したことはないと思います

どちらも広い意味での行動の変化であるため、私はそれらをバックポートしたくありません。

https://github.com/pallets/flask/pull/1996が許容できるソリューションだと思い

ただし、 https：//github.com/pallets/werkzeug/pull/998の修正はあまり良くありません。 アプリケーションは、独自のハンドラーのソケットを使用して実行していることから、これらの例外を合法的に発生させる可能性があり、それらも無音になります。 理想的な解決策は、これらが発生した場所でキャッチされ、 handle_errorが認識して無視できるカスタム例外クラスとして再発生することです。 おそらくSocketServerを変更したりオーバーロードしたりしたくないことを考えると、私の投票はこの部分をそのままにしておくことだと思います。 EPIPEはコンソールにダンプされますが、Python 2でのみ、少なくとも他の修正が行われた後はサーバーを停止しません。これは無害であり、私が作成する前の過去の動作です。 passthrough_errors変更。

ただし、説明する動作は、PASSTHROUGH_ERRORSが有効になっている場合にのみ発生します。 それ以外の場合、例外はFlask内からキャッチされます。

しかし、この美容上の改善はそれだけの価値はないと思います。

2016年8月27日午後6時29分30秒CESTでは、ミゲルGrinbergの[email protected]は書きました：

https://github.com/pallets/flask/pull/1996は許容できると思い
解決。 重要なことは、それが一般的なケースを修正することです
例外を伝播させたくありません。 伝播したい場合は、
次に、デバッグします。その場合、socket.errorを取得します。
すべきでないときに伝播することは大したことではありません。

https://github.com/pallets/werkzeug/pull/998修正は素晴らしいではありません
けれど。 アプリケーションは、これらの例外を合法的に発生させる可能性があります
独自のハンドラーのソケットで実行していること、そしてそれらは
同様に沈黙する。 理想的な解決策は、これらがキャッチされることです
それらが発生した場所で、カスタム例外として再発生します
handle_errorが認識して無視できるクラス。 私たちを考えると
おそらくSocketServerを変更したり、オーバーロードしたくないと思います。
投票は、この部分をそのままにしておくことです。 EPIPEはにダンプされます
コンソールですが、Python 2でのみ、少なくとも停止することはありません
他の修正が入った後のサーバー。それは無害であり、それは
私が作る前に、過去に存在した行動
passthrough_errors変更。

あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください。
https://github.com/pallets/werkzeug/issues/954#issuecomment -242926832

K-9Mailを使用してAndroidデバイスから送信されました。 簡潔に申し訳ありません。

マスターで修正されました。

説明する動作は、PASSTHROUGH_ERRORSが有効になっている場合にのみ発生します。

はい、その詳細は省略しました。 ただし、この変更はPython 3にも影響しますが、これは問題ではありません。 Py3では、パススルーエラーが有効になっていると、アプリケーションによって発生した正当なsocket.errorが無音になります。

マスターはwfmのようで、次のリリースを楽しみにしています、ありがとう！

こんにちは、私はNGINXの背後で実行されているWerkzeug開発サーバーを使用しています。同じ問題に直面しています。誰かがこれを手伝ってくれる可能性があります。
11:13:11 web.1 | 127.0.0.1 - - [15/Sep/2016 11:13:11] "GET /api/method/frappe.utils.print_format.download_pdf?doctype=Purchase%20Order&name=PO-00001&format=PO&no_letterhead=0 HTTP/1.1" 200 - 11:13:11 web.1 | Error on request: 11:13:11 web.1 | Traceback (most recent call last): 11:13:11 web.1 | File "/home/ommi/frappe-bench/env/lib/python2.7/site-packages/werkzeug/serving.py", line 193, in run_wsgi 11:13:11 web.1 | execute(self.server.app) 11:13:11 web.1 | File "/home/ommi/frappe-bench/env/lib/python2.7/site-packages/werkzeug/serving.py", line 184, in execute 11:13:11 web.1 | write(data) 11:13:11 web.1 | File "/home/ommi/frappe-bench/env/lib/python2.7/site-packages/werkzeug/serving.py", line 152, in write 11:13:11 web.1 | self.send_header(key, value) 11:13:11 web.1 | File "/usr/lib/python2.7/BaseHTTPServer.py", line 401, in send_header 11:13:11 web.1 | self.wfile.write("%s: %s\r\n" % (keyword, value)) 11:13:11 web.1 | IOError: [Errno 32] Broken pipe

助けてください

Ragavは、werkzeugの組み込み開発の代わりに別のアプリケーションサーバーを使用します
サーバー、gunicornのように。 現在、これが唯一の解決策です。

2016年9月15日8時07分GMT + 02：00 Ragav [email protected] ：

こんにちは、私はNGINXの背後で実行されているWerkzeug開発サーバーを使用しています。
同じ問題は誰でもこれで私を助けることができます、 `` `
11:13:11 web.1 | 127.0.0.1 --- [2016年9月15日11:13:11]「GET
/api/method/frappe.utils.print_format.download_pdf？
doctype = Purchase％20Order＆name = PO-00001＆format = PO＆no_letterhead = 0
HTTP / 1.1 "200-
11:13:11 web.1 | リクエストに応じてエラー：
11:13:11 web.1 | トレースバック（最後の最後の呼び出し）：
11:13:11 web.1 | ファイル "/ home / ommi / frappe-bench / env /
lib / python2.7 / site-packages / werkzeug / serving.py "、193行目、run_wsgi
11:13:11 web.1 | execute（self.server.app）
11:13:11 web.1 | ファイル "/ home / ommi / frappe-bench / env /
lib / python2.7 / site-packages / werkzeug / serving.py "、184行目、実行中
11:13:11 web.1 | write（data）
11:13:11 web.1 | ファイル "/ home / ommi / frappe-bench / env /
lib / python2.7 / site-packages / werkzeug / serving.py "、152行目、書き込み
11:13:11 web.1 | self.send_header（key、value）
11:13:11 web.1 | ファイル "/usr/lib/python2.7/BaseHTTPServer.py"、行401、
send_headerで
11:13:11 web.1 | self.wfile.write（ "％s：％s \ r \ n"％（キーワード、値））
11:13:11 web.1 | IOError：[Errno32]壊れたパイプ

助けてください

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/pallets/werkzeug/issues/954#issuecomment -247243400、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AA6MZ6DNiRIfL91CLeYOoA70W9_nQQzGks5qqOCMgaJpZM4I58cy
。

最近の修正コミットに基づいて、passthrough_errors = Falseを指定してapp.runを呼び出すことでこの問題を修正することができました。 YMMV

クラッシュの原因となったバグは、2016年12月21日にリリースされたバージョン0.12で

• 内部サーバーエラー（プルリクエスト＃2006）を返す代わりに、開発サーバーをクラッシュさせた動作の変更を元に戻します。

バージョン0.12は先週リリースされたばかりです。

2017年3月20日月曜日の09:05:00 AM -0700に、AlanRotmanは次のように書いています。

クラッシュの原因となったバグは、2016年12月21日にリリースされたバージョン0.12で

• 内部サーバーエラー（プルリクエスト＃2006）を返す代わりに、開発サーバーをクラッシュさせた動作の変更を元に戻します。

-
開/閉状態を変更したため、これを受け取っています。
このメールに直接返信するか、GitHubで表示してください。
https://github.com/pallets/werkzeug/issues/954#issuecomment -287807602

私は今日ReleaseNotesを見たばかりで、この修正を長い間待っていました。

見てください： http ：
バージョン0.12
2016年12月21日にリリースされたコードネームPunsch。

https://pypi.python.org/pypi/Flask/0.12
サイズでアップロードされたファイルタイプPyバージョン
Flask-0.12-py2.py3-none-any.whl（md5）Python Wheel 2.7 2016-12-21 80KB
Flask-0.12.tar.gz（md5）ソース2016-12-21 519KB

ああ、はい、あなたはフラスコを意味します。 もちろん。

2017年3月20日月曜日09:22:15 AM -0700に、AlanRotmanは次のように書いています。

私は今日ReleaseNotesを見たばかりで、この修正を長い間待っていました。

見てください： http ：
バージョン0.12
2016年12月21日にリリースされたコードネームPunsch。

https://pypi.python.org/pypi/Flask/0.12
サイズでアップロードされたファイルタイプPyバージョン
Flask-0.12-py2.py3-none-any.whl（md5）Python Wheel 2.7 2016-12-21 80KB
Flask-0.12.tar.gz（md5）ソース2016-12-21 519KB

-
開/閉状態を変更したため、これを受け取っています。
このメールに直接返信するか、GitHubで表示してください。
https://github.com/pallets/werkzeug/issues/954#issuecomment -287813405

threaded = Trueモードでwerkzeugでflask0.12.2を実行しているときに、この問題に遭遇した人への注意：
スレッドモードでは、デフォルトでは、各werkzeugスレッドに実際にはまだこの問題があるようです。つまり、戻るのに時間がかかるルートを要求してからクライアントからの接続を閉じると、その特定のwerkzeugはIOError BrokenPipeをログに記録してから死ぬ。 サーバーは全体的に機能し続けますが、私のアプリケーションでは、これが何らかの形でメモリリークを引き起こしていることがわかりました。いずれかのスレッドでパイプが壊れた後、フラスコプロセスがゆっくりと成長し、すべてのRAM、次にSWAPを使い果たし、最後にOSによって殺されました。
app.runでpassthrough_errors = Falseを明示的に送信すると、問題が解決したようです。クライアントが切断したときにスレッドが停止することはなくなり、IOErrorを適切にログに記録してから、これもログに記録します（passthrough_errors = Falseを明示的に設定しないと見たことはありません）。

Exception happened during processing of request from ('127.0.0.1', 50652)
----------------------------------------

その後、サーバーは通常どおり実行を続けます。 メモリリークが再び発生するかどうかを確認するには、まだ数時間待つ必要がありますが、発生しないことを期待しています。

万が一、それが誰にとっても役立つ場合に備えて。

UbuntuVM上のKubernetesのUbuntuDockerコンテナでもこのエラーが発生しました。

Error on request:
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/werkzeug/serving.py", line 270, in run_wsgi
    execute(self.server.app)
  File "/usr/local/lib/python2.7/dist-packages/werkzeug/serving.py", line 261, in execute
    write(data)
  File "/usr/local/lib/python2.7/dist-packages/werkzeug/serving.py", line 227, in write
    self.send_header(key, value)
  File "/usr/lib/python2.7/BaseHTTPServer.py", line 412, in send_header
    self.wfile.write("%s: %s\r\n" % (keyword, value))
IOError: [Errno 32] Broken pipe

まったく新しいUbuntuxenial VMを作成し、KubernetesのUbuntu Dockerコンテナーで同じコードを実行しましたが、このエラーは表示されず、PythonFlaskは期待どおりに機能しました。 私のホスト（Ubuntu VM）に問題があったと思います。

@vhosakotアプリの設定方法を教えてください。 あなたと同じ環境で同様の問題が発生しました。

ルート関数では、ルーティング用の別の関数を使用しました。
その関数の応答からデータをフェッチしました。
そのデータで_loads（）_を使用すると、エラーが発生します。

...
response = get_contents().data
        if response:
            data = loads(response)
..

エラー： IOError: [Errno 32] Broken pipe