[issue26228] pty.spawn hangs on FreeBSD 9.3, 10.x
John Beck added the comment: Solaris has this problem also, and Chris' patch fixes it for us. -- nosy: +jbeck ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26228> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26524] document what config directory is used for
New submission from John Beck: Solaris ships Python versions 2.7, 3.4 and 3.5 at present. For 2.7, we ship both 32-bit and 64-bit versions; for 3.4 and 3.5 we only ship 64-bit versions. For 2.7, we ship /usr/lib/python2.7/config/ with the usual suspects (Makefile, Setup.config, config.c, install-sh, python.o, Setup, Setup.local, config.c.in, makesetup) thereunder for the 32-bit version but for the 64-bit version, we don't ship the equivalent directory at all. For 3.4 and 3.5, we ship /usr/lib/python3.[45]/config-3.[45]m/ with its usual suspects. We had a bug filed about the discrepancy in shipping the 32-bit but not the 64-bit version of that directory for 2.7. An investigation suggested the directory is not used for 2.7, nor did it seem used (per docs we could find) for 3.x. But testing revealed it is used for 3.x, as our builds failed, e.g.: error: invalid Python installation: unable to open /usr/lib/python3.4/config-3.4m/Makefile (No such file or directory) when we removed the config-3.[45]m directories. OK, fine, it was an experiment, so we'll keep the directories. But it was not clear to us from the docs we could find, such as: https://docs.python.org/3.6/extending/extending.html exactly how the config directory is used. This is a documentation enhancement request to clarify how the config directory is used. -- assignee: docs@python components: Documentation messages: 261477 nosy: docs@python, jbeck priority: normal severity: normal status: open title: document what config directory is used for versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26524> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26414] os.defpath too permissive
New submission from John Beck:
A bug has been filed against Solaris' internal version of Python, which is
largely the same (including in this case) as the base version we get from
python.org. The bug is that os.defpath starts with ':' and thus any Python
script run with a null PATH environment variable will use the current
working directory as its first entry. This is generally considered to
be bad practice, and especially dangerous for anyone running with root
privileges on a Unix box. So we intend to change Solaris' version of
Python to elide this, i.e., to apply the attached patch to our 2.7 version
and comparable patches to our 3.4 and 3.5 versions
As a precaution, I queried the security list before filing this bug, asking:
* Is this intentional? (Seems like it but I couldn't find any documentation
to confirm.)
* If so, why? (Feel free to point me to any docs I missed.)
* If it is intentional, and we were to change our version anyway, do you know
of any gotchas we should look out for? There were no regressions when I
ran the Python test suite.
and got the following reply:
---
From: Guido van Rossum <gu...@python.org>
Date: Sat, 20 Feb 2016 09:29:11 -0800
Subject: Re: [PSRT] os.defpath too permissive
Wow. That looks like something really old. I think you can just file
an issue with a patch for this at bugs.python.org. I agree that it
should be fixed. I don't think there are many users that would be
vulnerable, nor do I think that much code would break; the only use in
the stdlib has os.environ.get("PATH", os.defpath) so in all practical
cases it would get the user's $PATH variable (which is presumably
safe) anyway.
---
So I am now filing this bug as suggested.
--
components: Library (Lib)
files: 2.7-defpath.patch
keywords: patch
messages: 260703
nosy: jbeck
priority: normal
severity: normal
status: open
title: os.defpath too permissive
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42010/2.7-defpath.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26414>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25003] os.urandom() should call getrandom(2) not getentropy(2) on Solaris 11.3 and newer
John Beck added the comment: Confirmed that test_os runs cleanly on Solaris 12, for each of: * 2.7.10 (plus your patch from 98454:202c827f86df) * 3.4.3 (plus your patch from 98455:83dc79eeaf7f) * 3.5.0 (plus your patch from 98452:835085cc28cd) * 3.6 (tip) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25003> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25003] os.urandom() should call getrandom(2) not getentropy(2) on Solaris 11.3 and newer
John Beck added the comment:
I have tested your patch with 3.5, and it works fine, although I did have to
make a minor change to get test_os to pass. In test_os.py you had:
...
USE_GETENTROPY = ((sysconfig.get_config_var('HAVE_GETENTROPY') == 1)
and not sys.platform.startswith("sunos"))
HAVE_GETRANDOM = (sysconfig.get_config_var('HAVE_GETRANDOM_SYSCALL') == 1)
@unittest.skipIf(USE_GETENTROPY,
"getentropy() does not use a file descriptor")
@unittest.skipIf(HAVE_GETRANDOM,
"getrandom() does not use a file descriptor")
...
whereas I came up with this:
...
USE_GETENTROPY = ((sysconfig.get_config_var('HAVE_GETENTROPY') == 1)
and not sys.platform.startswith("sunos"))
HAVE_GETRANDOM = (sysconfig.get_config_var('HAVE_GETRANDOM') == 1)
HAVE_GETRANDOM_SYSCALL = (sysconfig.get_config_var('HAVE_GETRANDOM_SYSCALL') ==
1)
@unittest.skipIf(USE_GETENTROPY,
"getentropy() does not use a file descriptor")
@unittest.skipIf(HAVE_GETRANDOM,
"getrandom() does not use a file descriptor")
@unittest.skipIf(HAVE_GETRANDOM_SYSCALL,
"getrandom() does not use a file descriptor")
...
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25003>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25003] os.urandom() should call getrandom(2) not getentropy(2) on Solaris 11.3 and newer
John Beck added the comment: I have queried the engineer who owns the kernel bug and will post an update once I hear back from him. But as it is already almost midnight on Friday in his geo, it may well be Monday before I hear back. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25003> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25003] os.urandom() should call getrandom(2) not getentropy(2) on Solaris 11.3 and newer
John Beck added the comment: Yes, those patches work, with a caveat. While testing this, I found out why I had needed EINVAL earlier (and still do, for now): there is a bug in the Solaris implementation of getrandom(2). If flags are 0 and the buffer size > 1024, then it fails with EINVAL. That is only supposed to happen for a buffer that big if GNRD_RANDOM is set in flags but GNRD_NONBLOCK is not set. So until that bug is fixed, I have to patch py_getrandom() to treat EINVAL like ENOSYS and fall back to using /dev/urandom as if getrandom(2) were not supported. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25003> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25003] os.urandom() should call getrandom(2) not getentropy(2) on Solaris 11.3 and newer
John Beck added the comment: Sorry, let me try to clarify. ENOSYS is the correct errno value to check for, for the situation (e.g., Solaris < 11.3) of a non-existent system call. But EINVAL should also be checked for to make sure the system call was invoked with proper parameters. My builds of Python 3.5.0.X (don't recall whether X was a late Beta or release candidate) were core dumping because Python was making that syscall but not checking for EINVAL, and thus assuming the call was valid, when it was not. Sorry, I did not try to debug why it was invalid. But once I added EINVAL, alongside ENOSYS, as a reason to set getrandom_works to 0, then python started behaving properly. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25003> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25003] os.urandom() should call getrandom(2) not getentropy(2)
John Beck added the comment: Yes, the syscall was failing with EINVAL. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25003> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25003] os.urandom() should call getrandom(2) not getentropy(2)
John Beck added the comment: @haypo: Yes, that patch works (applied to 3.5.0rc3; proxy problems are preventing me from updating my clone of the default branch at the moment) i.e., pyconfig.h shows: #define HAVE_GETRANDOM_SYSCALL 1 To answer your other questions: * Calling syscall(SYS_getrandom, buffer, size, 0) does work on Solaris. * Our does declare syscall(). * Solaris does not use the GNU C library, but our own libc, which does support getrandom(3) as of Solaris 11.3 (which will be released in the near future) and Solaris 12 (which is in Beta but has a release date in the more distant future). Prior to applying this patch, I had needed to tweak py_getrandom() to recognize EINVAL in addition to ENOSYS as sufficient reason to turn off getrandom_works. I still have that tweak in place, but have not yet tried backing it out to see if things still behave with your patch. Let me know if there is any more information I can provide, and thanks for your attention to this issue. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25003> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25003] os.urandom() should call getrandom(2) not getentropy(2)
New submission from John Beck: A recent Solaris build upgrade resulted in a massive slowdown of a package operation (our package client is written in Python). Some DTrace revealed this was because os.urandom() calls had slowed down by a factor of over 300. This turned out to be caused by an upgrade of Python from 2.7.9 to 2.7.10 which included: - Issue #22585: On OpenBSD 5.6 and newer, os.urandom() now calls getentropy(), instead of reading /dev/urandom, to get pseudo-random bytes. By adding ac_cv_func_getentropy=no to our configure options, we were able to get back the performance we had lost. But our security experts warned: --- OpenBSD only has getentropy(2) and we are compatible with that. Linux has both getentropy(2) and getrandom(2) Solaris has getentropy(2) and getrandom(2). The bug is in Python it should not use getentropy(2) for the implementation of os.urandom() unless it builds its own DRBG (Deterministic Random Bit Generator) around that - which will mean it is "caching" and thus only calling getentropy() for seeding very infrequently. You can not substitute getentropy() for getrandom(), if you need randomness then entropy does not suffice. They are using getentropy(2) correctly in the implementation of _PyRandom_Init(). I would personally recommend that the upstream adds os.getentropy() changes os.urandom() to use getrandom(buf, sz, GRND_NONBLOCK) and os.random() to use getrandom(buf, sz, GRND_RANDOM). As it is the upstream implementation is arguably a security vulnerability since you can not use entropy where you need randomness. --- where by "upstream" he meant "python.org". So I am filing this bug to request those changes. I can probably prototype this in the reasonable near future, but I wanted to get the bug filed sooner rather than later. -- components: Interpreter Core messages: 249837 nosy: jbeck priority: normal severity: normal status: open title: os.urandom() should call getrandom(2) not getentropy(2) versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25003> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25004] test_mmap should catch f.close() failure in LargeMmapTests._make_test_file()
New submission from John Beck: When running test_mmap on a partition with < 4GB free, it back-traced: Traceback (most recent call last): File "/usr/lib/python3.4/test/test_mmap.py", line 728, in _make_test_file f.flush() OSError: [Errno 28] No space left on device During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.4/test/test_mmap.py", line 735, in test_large_offset with self._make_test_file(0x14FFF, b" ") as f: File "/usr/lib/python3.4/test/test_mmap.py", line 730, in _make_test_file f.close() OSError: [Errno 28] No space left on device but by wrapping the f.close() inside another try/except block, its failure was caught and the test was able to complete, resulting in a skip for this sub-test and an OK for the overall test. -- components: Tests files: 26-test_mmap.patch keywords: patch messages: 249840 nosy: jbeck priority: normal severity: normal status: open title: test_mmap should catch f.close() failure in LargeMmapTests._make_test_file() versions: Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40361/26-test_mmap.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25004> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23287] ctypes.util.find_library needlessly call crle on Solaris
John Beck added the comment: First, there are two related but somewhat separate issues here. Regarding the patches attached to http://bugs.python.org/issue20664 they seem fine. In theory, they should not be needed, as though it is true that dump(1) moved from /usr/ccs/bin to /usr/bin in Solaris 11, /usr/ccs/bin still exists as a sym-link to /usr/bin. But the patches are written in a cautious manner, so the Right Thing [tm] should happen in all circumstances. Regarding my assertion that 'the default library path is a constant on Solaris: /lib/64:/usr/lib/64 in 64-bit mode and /lib:/usr/lib in 32-bit mode', I stand by that but will clarify what I meant by default. What I meant was this is what the system provides, though users may customize as needed. I hope that helps. If not, I'm happy to continue the conversation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23287 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24299] 2.7.10 test__locale.py change breaks on Solaris
John Beck added the comment: (Apologies for not responding on May 27 when you posted the patch; I failed to notice the Added file: line in the e-mail notification.) Yes! The patch you posted fixes the issue. Thank you! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24299 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24299] 2.7.10 test__locale.py change breaks on Solaris
New submission from John Beck: The upgrade from 2.7.9 to 2.7.10 resulted in test__locale failing. This test had previously succeeded. The difference is that the thousands-separator for the fr_FR locale in known_numerics was changed from '' (i.e., unknown) to ' ' (i.e. space). But on Solaris, '\xa0' (i.e., non-break space in ISO8859-1) is what the fr_FR locale returns for LC_NUMERIC's thousands-separator. I inquired with our Globalization experts, who replied: --- The short answer is that CLDR defines the group separator as no-break space (U+00A0): http://st.unicode.org/cldr-apps/v#/fr/Symbols/ so the solaris locale fr_FR (=fr_FR.ISO8859-1) is correct. The long answer is that the situation is confusing, the fr_FR.ISO8859-1 defines the thousands_sep as no-break space, but fr_FR.UTF-8 defines the thousands_sep as space (U+0020). There is no technical limit, but combination of POSIX [1] and C language [2] limits the thousands_sep to single byte character. The no-break space is single byte character in ISO8859-1, but multibyte in UTF-8. [1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.html#tag_07_03_04 [2] http://en.cppreference.com/w/c/locale/lconv http://en.cppreference.com/w/c/language/character_constant --- The attached patch fixes the test on Solaris. It is not clear if this is the Right Answer for all platforms, but I offer the attached patch in case it helps anyone else. -- components: Library (Lib) files: 25-test__locale.patch keywords: patch messages: 244181 nosy: jbeck priority: normal severity: normal status: open title: 2.7.10 test__locale.py change breaks on Solaris type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file39520/25-test__locale.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24299 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1298835] Add a vendor-packages directory for system-supplied modules
Changes by John Beck john.b...@oracle.com: -- nosy: +jbeck ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1298835 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24077] man page says -I implies -S. code says -s. Should it be both?
New submission from John Beck:
The man page for Python (3.4 and 3.5) says:
-I Run Python in isolated mode. This also implies -E and -S. In
isolated mode sys.path contains neither the scripts directory
nor the users site-packages directory. All PYTHON* environment
variables are ignored, too. Further restrictions may be imposed
to prevent the user from injecting malicious code.
But the code says:
-I : isolate Python from the user's environment (implies -E and -s)
and the code to handle -I does:
case 'I':
Py_IsolatedFlag++;
Py_NoUserSiteDirectory++;
Py_IgnoreEnvironmentFlag++;
break;
where Py_NoUserSiteDirectory is the variable corresponding to the -s flag
rather than the -S flag. But it seems like -I should really imply both
-s and -S. So I am filing this bug primarily to find out whether or not
it really should be both. If so, great: a patch is attached; details
below. But if not, then the man page should be corrected.
The rest of this is written under the assumption that -I should imply -S
as well as -s.
Background: depending on which packages are installed on different Solaris
systems, test_site passes or not. Certain packages (e.g., dogpile.core,
dogpile.cache, repoze.lru) that have a .pth file with import types
which results in test_site.StartupImportTests failing because types has
been imported which is in the list of collections modules, none of which
are expected to be imported. So we thought well, -S should fix that
then noticed the man page saying -I implied -S which is how we got here.
Tweaking the code and man page so -I does imply -S was trivial. But three
other changes were needed:
1. In test_site.py, test_startup_imports() asserted that 'site' was in the
list of modules that had been imported. This is no longer true, so I
deleted the assert.
2. test_inspect failed because of a name error, that turned out to be
inspect.py calling exit instead of sys.exit. So the attached patch
corrects both of those. This fix is probably generally applicable
even if the -I should imply both -S and -s assumption turns out to
be false.
3. test_venv failed because it and the venv module were using -I to imply
-s and -E but not -S. Changing three instances of -Im to -Esm
(one in Lib/venv/__init__.py, the other two in Lib/test/test_venv.py)
fixed this. However, even if the -I should imply both -S and -s
assumption is true, this change may not be desirable in the general
case, but needed because of Solaris' hacky work-around for issue
1298835 not yet being fixed.'
I.e., we ship /usr/lib/python3.4/site-packages/vendor-packages.pth
with the one line:
import site; site.addsitedir('/usr/lib/python3.4/vendor-packages')
(likewise for other versions).
So this may not be desirable in general, but I mention it for the
sake of completeness.
--
components: Interpreter Core
files: 25-site-module.patch
keywords: patch
messages: 242248
nosy: dhduvall, jbeck
priority: normal
severity: normal
status: open
title: man page says -I implies -S. code says -s. Should it be both?
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file39233/25-site-module.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24077
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24077] man page says -I implies -S. code says -s.
John Beck added the comment: Thank you very much for clarifying that. I have updated the bug Title accordingly. -- title: man page says -I implies -S. code says -s. Should it be both? - man page says -I implies -S. code says -s. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24077 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24077] man page says -I implies -S. code says -s. Should it be both?
John Beck added the comment: Adding Christian Heimes to the nosy list; as the author of the fix for issue 16499, he seems an excellent person to answer the question and offer advice on the approaches discussed herein. -- nosy: +christian.heimes ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24077 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19561] request to reopen Issue837046 - pyport.h redeclares gethostname() if SOLARIS is defined
John Beck added the comment: We (Solaris engineering) have hit this issue after migrating from 2.6 being our default version of Python to 2.7 being the default. The specific component that broke was vim (version 7.4), trying to compile if_python.c: /usr/include/python2.7/pyport.h, line 645: identifier redeclared: gethostname current : function(pointer to char, int) returning int previous: function(pointer to char, unsigned long) returning int : /usr/include/unistd.h, line 412 We had this patched out in Python 2.6's Include/pyport.h: -#ifdef SOLARIS -/* Unchecked */ -extern int gethostname(char *, int); -#endif but for some reason that patch was not propagated to our 2.7 line. Until today, that is; I will be applying that patch shortly to both 2.7 and 3.4. -- nosy: +jbeck ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19561 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23584] test_doctest lineendings fails in verbose mode
New submission from John Beck: Issue 8473 fixed a problem with lineendings in test_doctest, but it appears not to work in verbose mode. Adding verbose=False to the doctest.testfile() invocations in test_lineendings() fixes this. Attaching a patch to fix this for both 2.7 and 3.4. -- components: Tests files: new.patch keywords: patch messages: 237191 nosy: jbeck priority: normal severity: normal status: open title: test_doctest lineendings fails in verbose mode versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file38331/new.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23584 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23287] ctypes.util.find_library needlessly call crle on Solaris
New submission from John Beck: On Solaris, in Lib/ctypes/util.py, we have code that looks for /usr/bin/crle and calls it to parse its output to try to determine the Default Library Path. This code broke recently (Solaris 12 build 65), as it expects to find a line starting with Default Library Path (ELF): but the (ELF) part of that line was removed because it was no longer needed. So we need a change here regardless. But it turns out that calling crle is not needed at all because the default library path is a constant on Solaris: /lib/64:/usr/lib/64 in 64-bit mode and /lib:/usr/lib in 32-bit mode. Thus I offer the attached patch for both 2.7 and 3.4. -- components: ctypes files: crle-fix.patch keywords: patch messages: 234417 nosy: jbeck priority: normal severity: normal status: open title: ctypes.util.find_library needlessly call crle on Solaris type: resource usage versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file37800/crle-fix.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23287 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21412] Solaris/Oracle Studio: Fatal Python error: PyThreadState_Get when built --with-pymalloc
John Beck added the comment: Ned: yes, I can confirm that the patch from http://bugs.python.org/issue21166 does indeed fix the problem. Thank you very much! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21412 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22148] frozen.c should #include importlib.h instead of importlib.h
John Beck added the comment: Hm, that is strange. My reading of the semantics of foo.h vs foo.h was that they are almost the same, except that foo.h has the additional semantic of searching the local directory (wherever the .c file is that is #include'ing it) first. So if other platforms require that, and we require the opposite of that, then it seems neither Makefile nor configure tweaking would help, and the needs of the many outweigh the needs of the few (or the one), and we will just patch this privately in our internal repo. Thanks for your consideration. -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22148 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22148] frozen.c should #include importlib.h instead of importlib.h
New submission from John Beck: Background: on Solaris, we build Python and various modules 64-bit. To make this work with our general 64-bit changes, we use foo/64 as the path for our shared objects (.so files) rather than foo, for various values of foo (e.g., /usr/lib, /usr/lib/python3.4, etc.). We had to tweak Lib/importlib/_bootstrap.py to implement this. In so doing, we learned that Python/frozen.o does not pick up this change. The reason is that Python/frozen.c has a #include of importlib.h. But because of the quotes, it looks in the same directory for importlib.h . But when we rebuild importlib.h (via _freeze_importlib), the rebuilt importlib.h is placed into our build dir, not $srcdir. But '#include importlib.h' looks first for $srcdir/Python/importlib.h, finds the old one, then uses it without finding the rebuilt one over in the build dir. Although the description of the problem is rather convoluted, the fix is fortunately extremely simple: change importlib.h to importlib.h, i.e., change the quotes to angle-brackets, per the attached patch. -- components: Interpreter Core files: frozen-path.patch keywords: patch messages: 224885 nosy: jbeck priority: normal severity: normal status: open title: frozen.c should #include importlib.h instead of importlib.h versions: Python 3.4 Added file: http://bugs.python.org/file36276/frozen-path.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22148 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21412] core dump in PyThreadState_Get when built --with-pymalloc
John Beck added the comment: Victor: * This is not a SPARC-specific issue; the exact same failure occurs on x86. * I had built Python 3.3 (some time ago) but only --without-pymalloc. But I tried just now rebuilt Python 3.3 --with-pymalloc, and it failed in the exact same way. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21412 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21412] core dump in PyThreadState_Get when built --with-pymalloc
John Beck added the comment: Victor: sure; see attached. -- Added file: http://bugs.python.org/file35140/where.out ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21412 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21412] core dump in PyThreadState_Get when built --with-pymalloc
New submission from John Beck: I am porting Python 3.4.0 to Solaris 12. The Makefile I inherited from my predecessor had --without-pymalloc as an option to be passed to configure. Curious why, I removed this line, only to find that after python was built, it core dumped: LD_LIBRARY_PATH=/builds/jbeck/ul-python-3/components/python/python34/build/sparcv9 ./python -E -S -m sysconfig --generate-posix-vars Fatal Python error: PyThreadState_Get: no current thread make[3]: *** [pybuilddir.txt] Abort (core dumped) But if I add the --without-pymalloc line back to my Makefile, everything works fine. Note that although this example was on sparc, the exact same thing occurred on x86. I searched for a similar bug but did not find out; please feel free to close this as a duplicate if there is one that I missed. I also suspect I have not provided enough information, out of a desire not to trigger information overload. But I would be happy to provide whatever specifics might be requested. -- components: Interpreter Core messages: 217723 nosy: jbeck priority: normal severity: normal status: open title: core dump in PyThreadState_Get when built --with-pymalloc type: crash versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21412 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21412] core dump in PyThreadState_Get when built --with-pymalloc
John Beck added the comment: Using Oracle Studio 12.3, same as mentioned in http://bugs.python.org/issue15963#msg170661 (as Stefan pointed out). I am using some of those flags but not all of them. I will try the others when I have a chance, then report back. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21412 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13405] Add DTrace probes
Changes by John Beck john.b...@oracle.com: -- nosy: +jbeck ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13405 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
