_PyEvalFramePushAndInit_Ex warning: 'stack_array' may be used uninitialized

[utkonos]

Bug report

Bug description:

Probably a false positive, but this appears during build from source:

gcc  -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O3 -Wall  -flto=auto  -fno-semantic-interposition -flto -fuse-linker-plugin -ffat-lto-objects -g -std=c11 -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Wstrict-prototypes -Werror=implicit-function-declaration -fvisibility=hidden -fprofile-generate -I./Include/internal -I./Include/internal/mimalloc  -I. -I./Include    -fPIC -c ./Modules/mmapmodule.c -o Modules/mmapmodule.o
    default: Python/ceval.c: In function ‘_PyEvalFramePushAndInit_Ex’:
    default: Python/ceval.c:1900:38: warning: ‘stack_array’ may be used uninitialized [-Wmaybe-uninitialized]
    default:  1900 |     _PyInterpreterFrame *new_frame = _PyEvalFramePushAndInit(
    default:       |                                      ^~~~~~~~~~~~~~~~~~~~~~~~
    default:  1901 |         tstate, func, locals,
    default:       |         ~~~~~~~~~~~~~~~~~~~~~
    default:  1902 |         newargs, nargs, kwnames, previous
    default:       |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    default:  1903 |     );
    default:       |     ~
    default: Python/ceval.c:1823:1: note: by argument 4 of type ‘const union _PyStackRef *’ to ‘_PyEvalFramePushAndInit’ declared here
    default:  1823 | _PyEvalFramePushAndInit(PyThreadState *tstate, _PyStackRef func,
    default:       | ^~~~~~~~~~~~~~~~~~~~~~~
    default: Python/ceval.c:1869:17: note: ‘stack_array’ declared here
    default:  1869 |     _PyStackRef stack_array[8];
    default:       |                 ^~~~~~~~~~~

CPython versions tested on:

3.14

Operating systems tested on:

Linux

Linked PRs

• gh-142168: Initalize may be used but uninitialized stack_array. #142192

[CodeMaverick-143]

is anyone working on this issue , If not can you assign me this issue

[gkirchou]

Hit the same issue today.

I am not sure what's the context to leave it not initialized. This is probably fixable by initializing _PyStackRef stack_array[8] with {0}. Send a small PR to address this.

[picnixz]

AFAICT, this is a false positive:

_PyStackRef stack_array[8];
if (...) {
  /* doesn't use stack_array */
} else {
  if (nargs <= 8) {
	newargs = stack_array;
  } else {
	newargs = ...
  }

  for (i = 0; i < nargs; ++i) {
	newargs[i] = ...;
  }
}

In particular newargs[0..nargs-1] will be filled with the initialized values. And later we only read the first nargs values so there shouldn't be an issue.

[picnixz]

@ZeroIntensity I know we had smilar issues in the past, did we consider them to be false positive or worth to be fixed? (also it looks like it's being compiled with -Wall)

[ZeroIntensity]

I think we've fixed similar issues in the past, but does this occur on debug builds? IIRC, release builds already have a bunch of warnings anyway.

[chris-eibl]

AFAICT, this is a false positive:

Yeah, this is definitely a false positive and IMHO initializing in this hot path is not the way to go, but should be solved by suppressing the warning with a pragma.

See #132314, and #132376 and #134207.

Depending on the compiler version this warning can happen, but @vstinner did not like the pragma (#134207 (comment)) and hence @StanFromIreland closed the PR ...

Maybe this can be reconsidered since this is a recurring issue?

[picnixz]

I'll consiider it as a duplicate of #132314. Not for the same file but still a duplicate (and I think the OP is the same as well).