Core dump with specific call of find_frozen

[federicovalenso]

Crash report

What happened?

>>> from importlib import _imp
>>> _imp.find_frozen("zipimport", withdata=True)
python3: Objects/memoryobject.c:733: PyMemoryView_FromMemory: Assertion `mem != ((void *)0)' failed.
Aborted (core dumped)

python is configured with --with-pydebug --with-trace-refs --with-assertions

I think it happens here

CPython versions tested on:

3.11

Operating systems tested on:

Linux

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

Python 3.11.9 (main, Oct 30 2024, 09:46:33) [GCC 13.2.0]

Linked PRs

• gh-126171: fix possible null dereference in _imp_find_frozen_impl #126566
• [3.13] gh-126171: fix possible null dereference in _imp_find_frozen_impl (GH-126566) #126567
• [3.12] gh-126171: fix possible null dereference in _imp_find_frozen_impl (GH-126566) #126568

[sobolevn]

@federicovalenso how do you find these problems? Do you use some kind of tooling for that?

[ZeroIntensity]

I'm guessing it's a static analyzer. Anyways, I can take a look at this later today, unless @picnixz has already started working on it.

[picnixz]

I'm guessing it's a static analyzer. Anyways, I can take a look at this later today, unless @picnixz has already started working on it.

Please do so! I have some ongoing work elsewhere but I don't mind reviewing it!

[federicovalenso]

I'm sorry for late answer.

I'm guessing it's a static analyzer.

@sobolevn , @ZeroIntensity , you're right.

[ZeroIntensity]

We're fine with it as long as the crashes are actual bugs and not false positives (there have been false positive reports from static analyzers here in the past). But you seem to know what's real and what's not, keep doing what you're doing :)

[picnixz]

@ZeroIntensity I have some time now; do you want me to take on that task or were you already working on it?

[ZeroIntensity]

Go for it, I didn't get to this yesterday. I'll be happy to review your PR!

[picnixz]

Actually, I couldn't reproduce it on 3.12+ (even with the correct flags). It appears that it has been patched at some point. @federicovalenso can you 1) verify this 2) try to run your static analyzer tool on 3.12+ builds instead please? Thank you in advance!

[federicovalenso]

@picnixz , yeah, I'll do that, but it requires some time.

[sobolevn]

Otherwise, in order not to have a pending label for too long, I'd suggest closing this issue for now and come back later.

There's no real problem in having an issue with the "pending" label :)
Let's resolve the issue first: with finding the proper reproducer or with finding that it was fixed already. And then we can completelly close the issue.

[federicovalenso]

@picnixz , I couldn't reproduce it on 3.12+ too. Also I did static analysis, it still continues to complain about the same place in the code.

[picnixz]

Also I did static analysis, it still continues to complain about the same place in the code.

What does it say for this line? does it say that it's unsafe, or can lead to a core dump? (or something like that?)

[federicovalenso]

@picnixz , sorry for late answer. Analyzer doesn't like this line. It states that data is previously assigned to NULL, and in case of withdata == False dereference in Py_DECREF happens. It can happen when origname == NULL, but I can't reproduce it. Then I look around I found another, more serious problem with crash.

[picnixz]

Ah I see. Yes, we should use a Py_XDECREF just in case.

[picnixz]

@federicovalenso If you want to make a PR, go ahead, otherwise I'll do it a bit later.