Description

hutuhutong

opened on Aug 18, 2025

Issue body actions

Crash report

What happened?

When creating a deeply nested chain of filter() iterators, Python 3.12 can handle it (although very slow), but Python 3.13 results in a segmentation fault instead of raising an exception.

This appears to be a regression in Python 3.13’s iterator implementation, as user code should never cause a segfault. Ideally, this should raise a RecursionError or another Python exception, not crash the interpreter.

if __name__ == '__main__':
    import sys
    import gc
    
    def main():
        i = filter(bool, range(1000000))
        for _ in range(100000):
            i = filter(bool, i)
        print(list(i))

    #sys.setrecursionlimit(1000000)
    main()

CPython versions tested on:

3.13

Operating systems tested on:

Linux

Output from running 'python -VV' on the command line:

Python 3.13.2 crashes with:Segmentation fault (core dumped) Python 3.12.9 executes successfully (though very slow).

Linked PRs

• [3.13]gh-137894: Fix segmentation fault in deeply nested filter() iterator chains #137895
• gh-137894: Fix segmentation fault in deeply nested filter() iterator chains #137896

Activity

1. hutuhutong

   added

   type-crashA hard crash of the interpreter, possibly with a core dumpA hard crash of the interpreter, possibly with a core dump

   on Aug 18, 2025
2. sobolevn

   added

   3.13only security fixesonly security fixes

   3.14bugs and security fixesbugs and security fixes

   3.15bugs and security fixesbugs and security fixes

   interpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)

   on Aug 18, 2025
3. tangyuan0821

   added a commit that references this issue on Aug 18, 2025

   pythongh-137894:Fix os.makedirs to properly pass mode parameter to re…

   8c26178
4. serhiy-storchaka commented on Aug 18, 2025

   

   serhiy-storchaka

   on Aug 18, 2025

   Member

   More actions

   See other similar issues:

   • deeply nested itertools objects segfault #58218
   • Segfault with deeply nested starmap calls #58712
   • Segfault on recursive itertools.chain.from_iterable #67100
   • segfault caused by nested calls to map() #68794
   • Recursive starmap causes Segmentation fault #74483
5. serhiy-storchaka commented on Aug 18, 2025

   

   serhiy-storchaka

   on Aug 18, 2025

   Member

   More actions

   This is an exact duplicate of

   • Сrash when deleting deeply recursive iterator wrappers #61502

   which was closed as a duplicate of #58218.
6. picnixz commented on Aug 18, 2025

   

   picnixz

   on Aug 18, 2025

   Member

   More actions

   I'm going to close it as a duplicate as well and not planned as the original was considered not worth the fix (which I agree as it's not a straightforward one).
7. picnixz

   closed this as a duplicateof Сrash when deleting deeply recursive iterator wrappers #61502 on Aug 18, 2025
8. sergey-miryanov commented on Nov 6, 2025

   

   sergey-miryanov

   on Nov 6, 2025

   Contributor

   More actions

   FTR, I have added _Py_EnterRecursiveCall to the filter_next (sergey-miryanov@d3b76ee) and have following microbenchmark's results:

   Windows 11, x64, CPU 11th Gen Intel(R) Core(TM) i5-11600K @ 3.90GHz

   +----------------+--------------+------------------------+
   | Benchmark      | main-windows | filter-windows         |
   +================+==============+========================+
   | filter-1000    | 119 ms       | 114 ms: 1.04x faster   |
   +----------------+--------------+------------------------+
   | filter-2000    | 238 ms       | 230 ms: 1.03x faster   |
   +----------------+--------------+------------------------+
   | filter-4000    | 484 ms       | 469 ms: 1.03x faster   |
   +----------------+--------------+------------------------+
   | filter-8000    | 991 ms       | 959 ms: 1.03x faster   |
   +----------------+--------------+------------------------+
   | filter-16000   | 2.00 sec     | 1.93 sec: 1.03x faster |
   +----------------+--------------+------------------------+
   | Geometric mean | (ref)        | 1.03x faster           |
   +----------------+--------------+------------------------+
   

   Ubuntu 24.04, build with --lto=full, same CPU:

   +----------------+------------+------------------------+
   | Benchmark      | main-linux | filter-linux           |
   +================+============+========================+
   | filter-1000    | 119 ms     | 120 ms: 1.01x slower   |
   +----------------+------------+------------------------+
   | filter-2000    | 242 ms     | 244 ms: 1.01x slower   |
   +----------------+------------+------------------------+
   | filter-4000    | 493 ms     | 497 ms: 1.01x slower   |
   +----------------+------------+------------------------+
   | filter-8000    | 1.01 sec   | 1.01 sec: 1.01x slower |
   +----------------+------------+------------------------+
   | filter-16000   | 2.02 sec   | 2.05 sec: 1.01x slower |
   +----------------+------------+------------------------+
   | Geometric mean | (ref)      | 1.01x slower           |
   +----------------+------------+------------------------+
   

   Microbenchmark

   import pyperf
   import functools
   runner = pyperf.Runner()
   
   def bench(loops):
       i = filter(bool, range(10000))
       for _ in range(loops):
           i = filter(bool, i)
       list(i)
   
   for size in (1000, 2000, 4000, 8000, 16000):
       func = functools.partial(bench, size)
       runner.bench_func(f'filter-{size}', func)

   Based on the results on Linux, I don't think it's worth adding yet.

Issue actions