[issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10
Bennet Fauber added the comment: One additional note on this. Thanks to a colleague at USC who pointed out that this bug does not seem to get exercised if one does not include `--enable-shared` at configuration. I confirmed this using the distributed Python-3.7.4.tgz file and `configure --prefix=/path/to/install`. The `make test` then runs to completion with no errors. Running `make distclean`, then rerunning with `configure --prefix=/path/to/install --enable-shared` will then exercise the bug, and the faulthandler test fails with a segfault. Applying the patch file attached to this report and rebuilding leads to `make test` passing all tests, also. If someone was trying to reproduce and did not configure shared libraries, then that would have failed to reproduce. -- nosy: +justbennet ___ Python tracker <https://bugs.python.org/issue21131> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10
Bennet Fauber added the comment: Perhaps I should add, that we are able to reproduce this behavior on this hardware Dell R640 Intel(R) Xeon(R) Gold 6140 CPU @ 2.30GHz Dell R740 Intel(R) Xeon(R) Gold 6130 CPU @ 2.10GHz Dell R440 Intel(R) Xeon(R) Silver 4116 CPU @ 2.10GHz Dell C6420 Intel(R) Xeon(R) Silver 4116 CPU @ 2.10GHz but not on other chips, such as a recent i5, Haswell family, and older. That may also make a difference if someone tries to reproduce this. -- ___ Python tracker <https://bugs.python.org/issue21131> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10
Bennet Fauber added the comment: I just tested the proposed change in Aha, that's interesting: SIGSTKSZ should be enough for 1 signal handler, but test_register_chain calls 2 signal handlers using the same stack. Can you please try the following patch? ``` diff --git a/Modules/faulthandler.c b/Modules/faulthandler.c index 2331051f79..e7d13f2b2d 100644 --- a/Modules/faulthandler.c +++ b/Modules/faulthandler.c . . . . -stack.ss_size = SIGSTKSZ; +stack.ss_size = SIGSTKSZ * 2; ``` and the segfault no longer occurs at the faulthandler test. Compiling and running the altstack.c using the system installed GCC 4.8.5 on CentOS 7.6.1810, kernel version 3.10.0-957.10.1.el7.x86_64 running on Dell R640 Intel(R) Xeon(R) Gold 6140 CPU @ 2.30GHz results in this output. ``` $ gcc -o altstack altstack.c $ ./altstack SIGSTKSZ = 8192 our signal handler User defined signal 1 ``` It does seem to me that relying on a statically set stack size when using dynamically loaded libraries is inviting similar problems in the future for the reasons that Peter enumerated: There is no telling now what the requirements will be for some new chip family, and one cannot predict now what additional (if any) memory requirements might be needed by the linker in the future. But, I think getting _some_ patch accepted and pushed to the main Python releases should have some priority, as the current state does seem undesirable. -- ___ Python tracker <https://bugs.python.org/issue21131> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10
Bennet Fauber added the comment: I updated the versions affected to include 3.6 and 3.7, both of which are affected. I am a bit concerned that the conversation might get fragmented, so I will put in the full URL to the newly created PR at GitHub here. https://github.com/python/cpython/pull/15276 just to make it easier for anyone else who finds this to see where things have gone. I am now, also, uncertain what the current status of https://github.com/python/cpython/pull/13649 is now. It seems that we are now waiting on review from someone from the core developers? -- versions: +Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue21131> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37565] test_faulthandler: test_register_chain() crash with SIGSEGV (signal 11) on Skylake chipset
Bennet Fauber added the comment: It would appear that jshelly was correct and this is resolved by fixing the problem isolated in issue 21131, which was closed and a patch was committed. https://github.com/python/cpython/pull/15276 -- nosy: +justbennet ___ Python tracker <https://bugs.python.org/issue37565> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27003] Python 3.5.1 fails at HTTPSTest with SSL CERT error
New submission from Bennet Fauber:
I downloaded the source tar file for Python 3.5.1 and compiled. Upon running
make test, it fails at
test_networked_good_cert (test_httplib.HTTPSTest) ... ERROR
Abbreviated Traceback looks like:
==
ERROR: test_networked_good_cert (test_httplib.HTTPSTest)
--
Traceback (most recent call last):
File "/tmp/bennet/Python-3.5.1/Lib/test/test_httplib.py", line 1325, in
test_networked_good_cert
h.request('GET', '/')
. . . .
File "/tmp/local/python-3.5.1/lib/python3.5/ssl.py", line 628, in do_handshake
self._sslobj.do_handshake()
ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed
(_ssl.c:645)
I have replicated this on CentOS 7, RHEL 6.5, and Ubuntu 16.04 Xenial with GCC
versions 4.8.5, 4.8.5, and 5.3.1, respectively.
There was a previous bug reported about expired certificates that was closed.
It appears that it's using CERT_localhost, defined at the top to be
keycert.pem, and that appears to be valid:
[bennet@flux-build-centos7-dev test]$ openssl x509 -in keycert.pem -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 15548457918976213582 (0xd7c7381919afc24e)
. . . .
Validity
Not Before: Oct 8 23:01:56 2010 GMT
Not After : Oct 5 23:01:56 2020 GMT
I can replicate the test outside of make with the attached script.
I tried to be complete reporting and searching for this first; I apologize if I
missed an obvious solution.
--
components: Build
files: test-python3-httplib.py
messages: 265339
nosy: Bennet Fauber
priority: normal
severity: normal
status: open
title: Python 3.5.1 fails at HTTPSTest with SSL CERT error
type: compile error
versions: Python 3.5
Added file: http://bugs.python.org/file42822/test-python3-httplib.py
___
Python tracker
<http://bugs.python.org/issue27003>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27003] Python 3.5.1 fails at HTTPSTest with SSL CERT error
Bennet Fauber added the comment:
Just for the sake of completeness, I tested outside of the test harness.
/sw/arcts/centos7/python-dev/3.5.1/bin/python3
[bennet@flux-build-centos7-dev test]$ python3
Python 3.5.1 (default, May 11 2016, 08:50:05)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-4)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import http.client
>>> conn = http.client.HTTPSConnection("www.python.org")
>>> conn.request("GET", "/")
>>> r1 = conn.getresponse()
>>> print(r1.status, r1.reason)
200 OK
I think that indicates that it can do certificate verification of some sort and
might be an indication that the issue is not with the setup but with the test.
There was some discussion of making the tests independent of connectivity in
Issue25940.
There are a couple of expired certs in the test directory, but they may not be
used; e.g.,
nokia.pem,
Not After : Sep 20 23:59:59 2012 GMT
sha256.pem
Not After : Feb 17 23:59:59 2014 GMT
I should have included this in the first submission. Sorry for any additional
mail this may generate.
--
___
Python tracker
<http://bugs.python.org/issue27003>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
