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 — Null characters in strings cause a C SystemError · Issue #97556 · python/cpython

Null characters in strings cause a C SystemError #97556

New issue
Copy link
New issue
Copy link
Closed
Closed
Null characters in strings cause a C SystemError#97556
Copy link
Labels
3.10 (EOL)end of lifeend of life3.11only security fixesonly security fixes3.12only security fixesonly security fixes3.9 (EOL)end of lifeend of lifetype-crashA hard crash of the interpreter, possibly with a core dumpA hard crash of the interpreter, possibly with a core dump

Description

@apccurtiss
apccurtiss
opened on Sep 26, 2022
Issue body actions

Crash report

Putting a null byte into a Python string causes a SystemError in Python 3.10, due to a call to strlen in the string parsing library. In Python 3.9, the following example runs without errors:

# -*- coding: latin-1 -*-
"""
<NULL>
"""

In Python 3.10, it raises SystemError: ../Parser/string_parser.c:219: bad argument to internal function.

Internally, the new string_parser library introduced in v3.10.0a1 uses a call to strlen to determine the string size, which is getting thrown off by the null byte. This call is actually unnecessary, as the length has already been calculated by the calling parser and can be retrieved with PyBytes_AsStringAndSize.

Error messages

For single line strings, the error is SystemError: Negative size passed to PyUnicode_New

For multiline strings, the error is SystemError: ../Parser/string_parser.c:219: bad argument to internal function

Linked PRs

  • gh-97556: Raise null bytes syntax error upon null in multiline string #104136
  • gh-97556: Fix crash on null characters in string literal parser #97577

Activity

Next
  1. apccurtiss
    added
    type-crashA hard crash of the interpreter, possibly with a core dumpA hard crash of the interpreter, possibly with a core dump
    on Sep 26, 2022
  2. vstinner commented on Sep 26, 2022

    @vstinner
    vstinner
    on Sep 26, 2022
    Member
    More actions

    This issue seems like a duplicate of the issue #96670.

  3. apccurtiss commented on Sep 26, 2022

    @apccurtiss
    apccurtiss
    on Sep 26, 2022
    Author
    More actions

    Ah, you're totally right. I found that one earlier, but misunderstood the core bug and re-discovered it. Thanks!

  4. apccurtiss
    closed this as completedon Sep 26, 2022
  5. apccurtiss commented on Sep 26, 2022

    @apccurtiss
    apccurtiss
    on Sep 26, 2022
    Author
    More actions

    Actually, I just re-read that issue, and I was a bit over-eager with closing this. I feel like this is a very specific fix which doesn't actually solve their use case: This particular issue only shows up in 3.10, and causes an internal parse error. That linked issue is present in every 3.x version I've tested, including after this fix. I believe a patch elsewhere in the parser is needed for that.

  6. apccurtiss
    reopened this on Sep 26, 2022
  7. gvanrossum commented on Sep 26, 2022

    @gvanrossum
    gvanrossum
    on Sep 26, 2022
    Member
    More actions

    Can you submit a fix?

  8. gvanrossum
    added
    3.11only security fixesonly security fixes
    3.10 (EOL)end of lifeend of life
    3.9 (EOL)end of lifeend of life
    3.12only security fixesonly security fixes
    on Sep 26, 2022
  9. apccurtiss commented on Sep 26, 2022

    @apccurtiss
    apccurtiss
    on Sep 26, 2022
    Author
    More actions

    Submitted a fix in this pull request

  10. bskinn commented on Apr 24, 2023

    @bskinn
    bskinn
    on Apr 24, 2023
    Contributor
    More actions

    I cannot repro OP's SystemError on this. I do observe Python 3.12's fix for null characters in single-quoted strings (SyntaxError: source code cannot contain null bytes per #97594, when run with 3.12.0a7), so going forward I'm focusing on triple-quoted strings.

    For Python 3.8.16, 3.9.16, and 3.10.0a1 (WSL Debian local builds), crasher.py with the following contents parses successfully (without error, I did not check correctness) when executed from the commandline ($ python3.<#> crasher.py):

    <BLANKLINE>
    '''
    <NUL>
    '''
    

    For Python 3.10.0b1 (WSL Debian local), 3.10.0 (WSL Debian local), 3.10.11 (WSL Debian local and Win11), 3.11.3 (WSL Debian local and Win11), and (importantly) 3.12.0a7 (WSL Debian local), parsing fails with SyntaxError: unterminated triple-quoted string literal.

    Interestingly, the attributed line number of the exception location changes in 3.12.0a7. It's reported as line 3 in 3.12.0a7, and as line 2 for all other versions tested.

    Regardless, the triple-quoted string case is not yet fixed in the fashion indicated by #96670 (comment), where strings containing null characters are explicitly rejected with an exception and message like SyntaxError: source code cannot contain null bytes.

  11. bskinn commented on Apr 25, 2023

    @bskinn
    bskinn
    on Apr 25, 2023
    Contributor
    More actions

    Attn @pablogsal as author of #97594.

  12. gvanrossum commented on Apr 25, 2023

    @gvanrossum
    gvanrossum
    on Apr 25, 2023
    Member
    More actions

    @lysnikolaou ^^

  13. 1 remaining item

  14. lysnikolaou
    added 2 commits that reference this issue on May 3, 2023

    pythongh-97556: Raise null bytes syntax error upon null in multiline …

    fa7a709

    gh-97556: Raise null bytes syntax error upon null in multiline string (…

    ef0df52
  15. vstinner commented on May 4, 2023

    @vstinner
    vstinner
    on May 4, 2023
    Member
    More actions

    Script to reproduce the issues:

    with open("script.py", "w") as fp:
        print("# -*- coding: latin-1 -*-", file=fp)
        print('"""', file=fp)
        print('\0', file=fp)
        print('"""', file=fp)

    Current behavior:

    • main branch (3.12): SyntaxError: unterminated triple-quoted string literal (detected at line 3)
    • 3.11: SystemError: Parser/string_parser.c:230: bad argument to internal function

    Oh, it seems like the main branch was just changed (40 min ago) by PR #104136 (just merged).

    @lysnikolaou: Do you consider backporting your change to Python 3.11?

  16. bskinn commented on May 4, 2023

    @bskinn
    bskinn
    on May 4, 2023
    Contributor
    More actions

    With the merge of #97594 and #104136, I believe what OP has raised is now resolved in main/3.12, and per #96670 (comment) the changes are not to be backported.

    Thus, I think this issue can be closed.

  17. vstinner commented on May 4, 2023

    @vstinner
    vstinner
    on May 4, 2023
    Member
    More actions

    SystemError: Parser/string_parser.c:230: bad argument to internal function sounds like a bug in Python.

    It's not as if Python 3.11 accepts NUL characters. The question is more about providing a better error message if it finds a NUL character.

  18. bskinn commented on May 4, 2023

    @bskinn
    bskinn
    on May 4, 2023
    Contributor
    More actions

    It was @gvanrossum's call not to backport the original fix, and I wouldn't presume to speak authoritatively for him. But, I assume the motivation is the xkcd 1172 aspect of changing the error message string.

  19. pablogsal commented on May 4, 2023

    @pablogsal
    pablogsal
    on May 4, 2023
    Member
    More actions

    I think we should backport this to 3.11

  20. gvanrossum commented on May 4, 2023

    @gvanrossum
    gvanrossum
    on May 4, 2023
    Member
    More actions

    Okay let’s backport.

    Reacted by Brian Skinn
  21. bskinn commented on May 4, 2023

    @bskinn
    bskinn
    on May 4, 2023
    Contributor
    More actions

    Should #97594 be backported also, then?

  22. lysnikolaou commented on May 4, 2023

    @lysnikolaou
    lysnikolaou
    on May 4, 2023
    Member
    More actions

    Backporting both makes the most sense to me, since just improving the error message would require much more work with the tokenizer buffer working the way it is. If no one has any serious concerns over this, I can work on backporting the necessary PRs.

  23. gvanrossum commented on May 4, 2023

    @gvanrossum
    gvanrossum
    on May 4, 2023
    Member
    More actions

    Let’s ask @pablogsal about that one.

    Reacted by Lysandros Nikolaou
  24. pablogsal commented on May 4, 2023

    @pablogsal
    pablogsal
    on May 4, 2023
    Member
    More actions

    Backporting both makes the most sense to me, since just improving the error message would require much more work with the tokenizer buffer working the way it is. If no one has any serious concerns over this, I can work on backporting the necessary PRs.

    Yeah, I prefer to backport the restriction to keep the changes to a minimum in 3.11 as making a bugfix for the error message can be much more complex 👍

    Reacted by Lysandros Nikolaou
  25. lysnikolaou commented on May 7, 2023

    @lysnikolaou
    lysnikolaou
    on May 7, 2023
    Member
    More actions

    Raising a SyntaxError when parsing NULL bytes has been backported to 3.11. I'm closing this.

  26. lysnikolaou
    closed this as completedon May 7, 2023
  27. vstinner commented on May 9, 2023

    @vstinner
    vstinner
    on May 9, 2023
    Member
    More actions

    I confirm that 3.11 and main branches now display the same output for ./python script.py (see #97556 (comment) to generate script.py).

      File "/home/vstinner/python/main/../3.11/script.py", line 3
        
    SyntaxError: source code cannot contain null bytes
    
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

    3.10 (EOL)end of lifeend of life3.11only security fixesonly security fixes3.12only security fixesonly security fixes3.9 (EOL)end of lifeend of lifetype-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 01402503 — 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.