GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Mutable heap PyStructSequence types can segfault after modifying n_fields · Issue #155322 · python/cpython

Mutable heap PyStructSequence types can segfault after modifying n_fields #155322

New issue
Copy link
New issue
Copy link
Open
Open
Mutable heap PyStructSequence types can segfault after modifying n_fields#155322
Copy link
Labels
interpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)type-crashA hard crash of the interpreter, possibly with a core dumpA hard crash of the interpreter, possibly with a core dump

Description

@BHUVANSH855
BHUVANSH855
opened on Aug 7, 2026
Issue body actions

Crash report

What happened?

Several heap PyStructSequence types can be crashed from pure Python by modifying the writable n_fields attribute on the type and then constructing a new instance.

The issue reproduces with at least:

  • os.terminal_size
  • os.stat_result
  • time.struct_time
  • resource.struct_rusage

Minimal reproducer:

import os

os.terminal_size.n_fields = 100000
os.terminal_size((1, 2))

This consistently terminates the interpreter with:

Segmentation fault (core dumped)

The crash also reproduces for other mutable heap PyStructSequence types by assigning a large value to n_fields before construction.

The backtrace shows the crash occurring in structseq_new_impl():

#0  __strlen_avx2()
#1  PyUnicode_FromString()
#2  PyDict_GetItemStringRef()
#3  structseq_new_impl() at Objects/structseq.c:243

At the point of failure:

max_len = 100000
i = 2
n_unnamed_fields = 0

From inspecting Objects/structseq.c, structseq_new_impl() uses the type's n_fields value to determine how many member names to process. After modifying n_fields from Python, the constructor eventually reaches a NULL member name, leading to a crash through PyDict_GetItemStringRef() and PyUnicode_FromString().

During investigation I also verified that immutable builtin structseq types such as sys.version_info are not affected because their type attributes cannot be modified and new instances cannot be created.

I searched the existing issue tracker using keywords including:

  • structseq_new_impl
  • PyStructSequence_NewType
  • n_fields
  • Objects/structseq.c
  • PyDict_GetItemStringRef
  • tp_members

but could not find an existing report describing this behavior.

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux

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

Python 3.16.0a0 (heads/main:e469fa9c807, Aug 7 2026, 09:37:12) [GCC 13.3.0]

Linked PRs

  • gh-155322: Validate mutable structseq layout attributes #155361

Activity

  1. BHUVANSH855
    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 7, 2026
  2. aisk
    added
    interpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)
    on Aug 7, 2026
  3. BHUVANSH855
    added a commit that references this issue on Aug 7, 2026

    pythongh-155322: Add NEWS entry for PyStructSequence crash fix

    77fde83
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    interpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)type-crashA hard crash of the interpreter, possibly with a core dumpA hard crash of the interpreter, possibly with a core dump

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      You are visitor 01402520 — GeezerVison does not store the pages you look up.
      Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.