| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
MUSL claims to support pthread_getattr_np, but the response returned is off by at least an order of magnitude compared to reality. This is apparently a long standing problem. MUSL also does not provide any way to detect directly that it is the libc. It would be possible to add things to configure to detect that MUSL is the compiler, but since this code has caused problems for a lot of non-glibc platforms, it seems easier to just restrict it to glibc.
| uintptr_t here_addr = _Py_get_machine_stack_pointer(); | ||
| # if defined(HAVE_PTHREAD_GETATTR_NP) && !defined(_AIX) && !defined(__NetBSD__) | ||
| # if defined(HAVE_PTHREAD_GETATTR_NP) && !defined(_AIX) && \ | ||
| !defined(__NetBSD__) && defined(__GLIBC__) |
There was a problem hiding this comment.
I don't think that this call is correct. It disables the call on FreeBSD.
Maybe check for "glibc or not Linux"?
Sorry, something went wrong.
There was a problem hiding this comment.
That would fix it for alpine, but not for emscripten or wasi (but I don't know what they actually need). I'd rather see it as if glibc or freebsd, and get rid of the rest, but glibc or not linux would work for my immediate concern.
Sorry, something went wrong.
There was a problem hiding this comment.
Well, let's start with fixing Alpine Linux.
Sorry, something went wrong.
There was a problem hiding this comment.
OK, done. Also added an XXX comment, since I think this needs more investigation. I'll put it on my todo list to post to the musl mailing list about it.
Sorry, something went wrong.
This exempts alpine but doesn't affect, eg, FreeBSD.
There was a problem hiding this comment.
LGTM
Sorry, something went wrong.
|
This looks good but it needs a news entry as it is a bugfix and needs to be backported to 3.14. |
Sorry, something went wrong.
Co-authored-by: Victor Stinner <vstinner@python.org>
|
I have added a news entry to move this PR forward and get this merged soon, will run through buildbots and merge. |
Sorry, something went wrong.
|
🤖 New build scheduled with the buildbot fleet by @kumaraditya303 for commit 6498d29 🤖 Results will be shown at: https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F134336%2Fmerge If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again. |
Sorry, something went wrong.
|
Kumar asked me to test libcst with this PR applied. I manually backported the substantive part of this PR to the 3.14 branch and built Python using pyenv in the musllinux docker container. I still see the segfault: https://gist.github.com/ngoldbaum/16fb37188d049edcd18296f809241798. Also looking close, I don't think the crash we saw in LibCST is caused by this, since we see it in 3.13, and I don't think the new stack size code ever went into 3.13? |
Sorry, something went wrong.
Yes, it is present in 3.14 and above. Looking at the backtrace of libcst it seems unrelated to this, a better test candidate for this would be scipy as that currently errors out with RecursionError like in scipy/scipy#23172. |
Sorry, something went wrong.
|
Thanks @bitdancer for the PR, and @kumaraditya303 for merging it 🌮🎉.. I'm working now to backport this PR to: 3.14. |
Sorry, something went wrong.
…ux (pythonGH-134336) (cherry picked from commit 1e9b8f2) Co-authored-by: R. David Murray <rdmurray@bitdance.com> Co-authored-by: Kumar Aditya <kumaraditya@python.org> Co-authored-by: Victor Stinner <vstinner@python.org>
|
GH-137175 is a backport of this pull request to the 3.14 branch. |
Sorry, something went wrong.
⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️Hi! The buildbot ARM64 Raspbian 3.x (tier-3) has failed when building commit 1e9b8f2. What do you need to do:
You can take a look at the buildbot page here: https://buildbot.python.org/#/builders/1678/builds/582 Failed tests:
Failed subtests:
Summary of the results of the build (if available): == Click to see traceback logsTraceback (most recent call last):
File "/home/stan/buildarea/3.x.stan-raspbian.nondebug/build/Lib/test/test_embed.py", line 1455, in test_init_setpythonhome
self.check_all_configs("test_init_setpythonhome", config,
~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
api=API_COMPAT, env=env)
^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/stan/buildarea/3.x.stan-raspbian.nondebug/build/Lib/test/test_embed.py", line 947, in check_all_configs
self.check_config(configs, expected_config)
~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/stan/buildarea/3.x.stan-raspbian.nondebug/build/Lib/test/test_embed.py", line 873, in check_config
self.assertEqual(config, expected)
~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^
AssertionError: {'argv': [''], 'base_exec_prefix': '/home/s[2395 chars]None} != {'_config_init': 1, 'isolated': False, 'use[2463 chars]alse}
{'_config_init': 1,
'_init_main': True,
'_install_importlib': True,
'argv': [''],
'base_exec_prefix': '/home/stan/buildarea/3.x.stan-raspbian.nondebug/build',
'base_executable': '/home/stan/buildbot/bin/python3',
'base_prefix': '/home/stan/buildarea/3.x.stan-raspbian.nondebug/build',
'buffered_stdio': True,
'bytes_warning': 0,
'check_hash_pycs_mode': 'default',
'code_debug_ranges': True,
'configure_c_stdio': False,
'context_aware_warnings': 0,
'cpu_count': -1,
'dev_mode': False,
'dump_refs': False,
'dump_refs_file': None,
- 'exec_prefix': '/home/stan/buildbot',
+ 'exec_prefix': '/home/stan/buildarea/3.x.stan-raspbian.nondebug/build',
'executable': '/home/stan/buildbot/bin/python3',
'faulthandler': False,
'hash_seed': 0,
'home': '/home/stan/buildarea/3.x.stan-raspbian.nondebug/build',
'import_time': 0,
'inspect': False,
'install_signal_handlers': True,
'int_max_str_digits': 4300,
'interactive': False,
'isolated': False,
'malloc_stats': False,
'module_search_paths': ['/home/stan/buildarea/3.x.stan-raspbian.nondebug/build/target/lib/python315.zip',
'/home/stan/buildarea/3.x.stan-raspbian.nondebug/build/Lib',
'/home/stan/buildarea/3.x.stan-raspbian.nondebug/build/build/lib.linux-aarch64-3.15',
'/home/stan/buildarea/3.x.stan-raspbian.nondebug/build/lib/python315.zip',
'/home/stan/buildarea/3.x.stan-raspbian.nondebug/build/lib/python3.15',
'/home/stan/buildarea/3.x.stan-raspbian.nondebug/build/lib/python3.15/lib-dynload'],
'module_search_paths_set': True,
'optimization_level': 0,
'orig_argv': [],
'parse_argv': False,
'parser_debug': False,
'pathconfig_warnings': True,
'perf_profiling': 0,
'platlibdir': 'lib',
- 'prefix': '/home/stan/buildbot',
+ 'prefix': '/home/stan/buildarea/3.x.stan-raspbian.nondebug/build',
'program_name': 'python3',
'pycache_prefix': None,
'pythonpath_env': '/home/stan/buildarea/3.x.stan-raspbian.nondebug/build/target/lib/python315.zip:/home/stan/buildarea/3.x.stan-raspbian.nondebug/build/Lib:/home/stan/buildarea/3.x.stan-raspbian.nondebug/build/build/lib.linux-aarch64-3.15',
'quiet': False,
'remote_debug': True,
'run_command': None,
'run_filename': None,
'run_module': None,
'safe_path': False,
'show_ref_count': False,
'site_import': True,
'skip_source_first_line': False,
'stdlib_dir': '/home/stan/buildarea/3.x.stan-raspbian.nondebug/build/lib/python3.15',
'sys_path_0': None,
'thread_inherit_context': 0,
'tracemalloc': 0,
'use_environment': True,
'use_frozen_modules': True,
'use_hash_seed': False,
'user_site_directory': True,
'verbose': 0,
'warn_default_encoding': False,
'warnoptions': [],
'write_bytecode': True,
'xoptions': {}}
|
Sorry, something went wrong.
|
Buildbot fail is unrelated to this PR. I am temporarily disabling the bot till I find a solution. |
Sorry, something went wrong.
…ux (python#134336) Co-authored-by: Kumar Aditya <kumaraditya@python.org> Co-authored-by: Victor Stinner <vstinner@python.org>
…ibc linux (pythonGH-134336) (python#137175) Co-authored-by: R. David Murray <rdmurray@bitdance.com> Co-authored-by: Kumar Aditya <kumaraditya@python.org> Co-authored-by: Victor Stinner <vstinner@python.org>
| Back | FazBrowse Home | New Git URL |
MUSL claims to support pthread_getattr_np, but the response returned is off by at least an order of magnitude compared to reality. This is apparently a long standing problem. MUSL also does not provide any way to detect directly that it is the libc. It would be possible to add things to configure to detect that MUSL is the compiler, but since this code has apparently caused problems for a lot of non-glibc platforms, it seems easier to just restrict it to glibc.