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 — "import hashlib" crashes on aarch64 after Finalize and re-initialize · Issue #121087 · python/cpython

"import hashlib" crashes on aarch64 after Finalize and re-initialize #121087

New issue
Copy link
New issue
Copy link
Closed
Closed
"import hashlib" crashes on aarch64 after Finalize and re-initialize#121087
Copy link
Labels
type-crashA hard crash of the interpreter, possibly with a core dumpA hard crash of the interpreter, possibly with a core dump

Description

@rdoeffinger
rdoeffinger
opened on Jun 27, 2024
Issue body actions

Crash report

What happened?

Compiling and linking below program results in a crash when run on aarch64 (macOS, Debian VM or Ubuntu 22 VM in Azure for example):

#include <Python.h>

int main(int argc, char *argv[])
{
Py_Initialize();
PyRun_SimpleString("import hashlib\nprint('test1')");
Py_Finalize();
Py_Initialize();
PyRun_SimpleString("import trace\ntrace.Trace().run('import hashlib')\nprint('test2')");
Py_Finalize();
return 0;
}

The trace in the second import is just for better context.
It seems not reproducible on Intel.
On a debug python build it asserts with:
testcase1: ../Python/getargs.c:2052: parser_init: Assertion `parser->kwtuple != NULL' failed.

The backtrace looks like this:
#7 0x0000fffff7906fec [PAC] in _PyArg_UnpackKeywords (
args=args@entry=0xfffff7fec5d8, nargs=nargs@entry=0,
kwargs=kwargs@entry=0x0, kwnames=kwnames@entry=0xfffff6620be0,
parser=parser@entry=0xfffff6f70790 <_parser.16>, minpos=minpos@entry=0,
maxpos=maxpos@entry=1, minkw=minkw@entry=0, buf=buf@entry=0xffffffffe180)
at ../Python/getargs.c:2371
#8 0x0000fffff6f57500 [PAC] in _hashlib_openssl_md5 (module=0xfffff6553d70,
args=args@entry=0xfffff7fec5d8, nargs=nargs@entry=0,
kwnames=kwnames@entry=0xfffff6620be0)
at ../Modules/clinic/_hashopenssl.c.h:343
#9 0x0000fffff780c010 [PAC] in cfunction_vectorcall_FASTCALL_KEYWORDS (
func=0xfffff656c050, args=0xfffff7fec5d8, nargsf=,
kwnames=0xfffff6620be0) at ../Objects/methodobject.c:438
#10 0x0000fffff77b6c18 [PAC] in _PyObject_VectorcallTstate (
tstate=0xfffff7f6e1f0 <_PyRuntime+475736>,
callable=callable@entry=0xfffff656c050, args=args@entry=0xfffff7fec5d8,
nargsf=nargsf@entry=9223372036854775808,
kwnames=kwnames@entry=0xfffff6620be0)
at ../Include/internal/pycore_call.h:92

Looking at the hashlib_openssl_md5 function, the use of static non-const structures seems very suspicious at least.

CPython versions tested on:

3.12

Operating systems tested on:

Linux, macOS

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

Python 3.12.4 (main, Jun 8 2024, 04:51:36) [Clang 15.0.0 (clang-1500.1.0.2.5)]

Activity

  1. rdoeffinger
    added
    type-crashA hard crash of the interpreter, possibly with a core dumpA hard crash of the interpreter, possibly with a core dump
    on Jun 27, 2024
  2. diegorusso commented on Jun 27, 2024

    @diegorusso
    diegorusso
    on Jun 27, 2024
    Contributor
    More actions

    @rdoeffinger thanks for raising the bug, I can take a look at this.

  3. rdoeffinger commented on Jul 11, 2024

    @rdoeffinger
    rdoeffinger
    on Jul 11, 2024
    Author
    More actions

    I did not test on Windows.
    Only macOS Arm, Linux Arm, Linux x86_64
    If you need to call the test function containing use of openssl function (vs. just importing/loading) then it might not be quite the same issue...

  4. diegorusso commented on Jul 12, 2024

    @diegorusso
    diegorusso
    on Jul 12, 2024
    Contributor
    More actions

    I confirm that this is still happening on 3.13 and 3.14 (main)

  5. diegorusso commented on Jul 12, 2024

    @diegorusso
    diegorusso
    on Jul 12, 2024
    Contributor
    More actions

    I have a fix that basically set to 0 the parser->once.v in the parser_clear. I ran all the tests but I'm not sure if I'm missing something else.
    Unfortunately I'll be away for some time and I'm not able to fix it now.

  6. diegorusso commented on Aug 20, 2024

    @diegorusso
    diegorusso
    on Aug 20, 2024
    Contributor
    More actions

    This is actually been fixed in the meantime by @neonene with #122481

    I tested the code in this issue and now it is working OK. I guess we can close this issue but I leave it to @rdoeffinger to verify.
    The fix went into 3.12.5.

  7. diegorusso commented on Aug 27, 2024

    @diegorusso
    diegorusso
    on Aug 27, 2024
    Contributor
    More actions

    I think this issue can be closed.

  8. picnixz commented on Aug 27, 2024

    @picnixz
    picnixz
    on Aug 27, 2024
    Member
    More actions

    Closing since the OP did not reply and the original issue is not reproducible anymore.

    Reacted by Diego Russo
  9. picnixz
    closed this as completedon Aug 27, 2024
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

    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 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.