Memory leak: the shared `validation_aborted_error` keeps every traceback it is raised through
评估
调研方向
从 graphql/validation/validate.py 开始，查看共享的 validation_aborted_error 在哪里被引发，并了解 validate() 如何处理达到 max_errors 的情况。issue 中的复现展示了 traceback 和内存增长；请在更改前后运行它，以确认重复调用不再保留不断增长的 traceback。每次 validation 调用都引发自己的错误，且内存增长趋于稳定时，即为完成。
由索引模型根据 Issue 内容生成。
描述
Since aab6d50 (first released in 3.3.0a3), validate() raises one shared, module-level ValidationAbortedError once max_errors is reached. When an existing exception object is raised again, Python adds the new frames to its existing __traceback__. So every aborted validation lengthens the singleton's traceback, and that traceback keeps those frames, and with them each request's document and validation context, alive for the life of the process.
Any client can trigger this by sending a query with more than 100 validation errors. In a long-running server, memory grows with every such request.
Reproduction (graphql-core 3.3.0, CPython 3.12):
import gc, tracemalloc
from graphql import build_schema, parse, validate
from graphql.validation.validate import validation_aborted_error
schema = build_schema("type Query { a: Int }")
document = parse("{ " + " ".join(f"f{i}" for i in range(101)) + " }")
tracemalloc.start()
validate(schema, document)
gc.collect()
base = tracemalloc.get_traced_memory()[0]
for _ in range(200):
validate(schema, document)
gc.collect()
tb, n = validation_aborted_error.__traceback__, 0
while tb:
n, tb = n + 1, tb.tb_next
print(n, (tracemalloc.get_traced_memory()[0] - base) // 1024, "KiB")
Result:
| Repeated calls | Traceback entries | Memory retained |
|---|---|---|
| 1 | 16 | 147 KiB |
| 10 | 88 | 1,389 KiB |
| 100 | 808 | 12,549 KiB |
| 200 | 1,608 | 24,820 KiB |
That is about 124 KiB more per aborted validation, with no upper limit. The same script on 3.2.13, which creates a new error each time, levels off at about 259 KiB.
Suggested fix: create a new ValidationAbortedError on each validate() call instead of reusing the module-level instance. Clearing __traceback__ before each raise would also work, but every caller's error list would still share one mutable error object.
- 主要语言
- Python
- 星标
- 532
- 派生
- 154
- 平均合并
- 1 天 9 小时
- 30 天内合并 PR
- 6
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 没有贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
graphql-python/graphql-core 的其他 Issue
-
`collect_subfields` memoization keyed on `id()` of `FieldDetails` that are not kept alive returns another field's subfields可能已有人在做 @jadenfix 于 7 天前认领。 未关闭
难度 3/5 1-2 天 新手友好度 72/100
graphql-python/graphql-core#284 · 1 条评论 ·
-
难度 1/5 1 小时以内 新手友好度 35/100
graphql-python/graphql-core#278 ·
-
难度 3/5 1-2 天 新手友好度 45/100
graphql-python/graphql-core#257 ·
-
难度 3/5 1-2 天 新手友好度 35/100
graphql-python/graphql-core#223 · 1 条评论 ·
-
documentation good first issue
难度 2/5 1-3 小时 新手友好度 35/100
graphql-python/graphql-core#220 · 4 条评论 ·
查看 graphql-python/graphql-core 的全部 Issue
相似的 Issue
-
bug P2 rust
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复
-
enhancement
难度 2/5 1-3 小时 新手友好度 72/100
jscott3201/rusty-bacnet#2085 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 84/100
evarness-ai/iris-harness#401 ·
-
难度 2/5 1-3 小时 新手友好度 76/100
sistemicorp/scripts#62 ·
-
area/mac help wanted needs-qa
难度 1/5 1 小时以内 新手友好度 76/100