Skip to content

Conversation

@vstinner
Copy link
Member

@vstinner vstinner commented Nov 14, 2025

These checks were invalid and failed randomly on FreeBSD.
@vstinner
Copy link
Member Author

These checks were invalid and failed randomly on FreeBSD.

It also fails on Alpine Linux.

@vstinner vstinner enabled auto-merge (squash) November 14, 2025 11:58
@vstinner vstinner merged commit a415a18 into python:main Nov 14, 2025
50 checks passed
@vstinner vstinner deleted the init_recursion branch November 14, 2025 14:56
@markshannon
Copy link
Member

If an assertion is failing, fix whatever is causing the invariant to be broken. Don't just remove the assert.

Please revert this change, and make an issue for the failures. Especially if it is "failing randomly".
I don't think #139653 is relevant.

It is a necessary invariant that the stack pointer lie between the top of the stack and the soft limit. If that is not the case, we need to fix it.

@vstinner
Copy link
Member Author

This PR is to repair FreeBSD and Alpine buildbots. These buildbot workers were crashing randomly (with an assertion error in fact). I suppose that WASI had the same issue but it was more likely on WASI so I already skipped the assertion on WASI.

If an assertion is failing, fix whatever is causing the invariant to be broken. Don't just remove the assert.

It's the following assertion which fails randomly:

    uintptr_t here_addr = _Py_get_machine_stack_pointer();
    ....
    assert(here_addr < ts->c_stack_top);

The code to get the stack top in hardware_stack_limits() is not reliable:

    uintptr_t top_addr = _Py_SIZE_ROUND_UP(here_addr, 4096);

Maybe one problem is that the assertion is not checked in the same function than hardware_stack_limits().

I don't have time to investigate this issue right now.

I suppose that you should be able to reproduce it if you disable the pthread_attr_getstack() code path in hardware_stack_limits().

@markshannon
Copy link
Member

This PR is to repair FreeBSD and Alpine buildbots.

It doesn't repair anything. It just leaves a latent bug to blow up later.

The code to get the stack top in hardware_stack_limits() is not reliable

Then fix that, or make an issue for me to fix. Please don't turn off asserts without any review.

Maybe one problem is that the assertion is not checked in the same function than hardware_stack_limits()

Sure, let's move the assert to make the point of failure clearer.

I suppose that you should be able to reproduce it if you disable the pthread_attr_getstack() code path in hardware_stack_limits()

I'll try that.

@markshannon
Copy link
Member

encukou pushed a commit to encukou/cpython that referenced this pull request Nov 17, 2025
…pythonGH-141551)

These checks were invalid and failed randomly on FreeBSD
and Alpine Linux.
StanFromIreland pushed a commit to StanFromIreland/cpython that referenced this pull request Dec 6, 2025
…python#141551)

These checks were invalid and failed randomly on FreeBSD
and Alpine Linux.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants