New submission from Jeffrey Walton :
I need to setup a Debian HURD test machine to investigate a problem I was
seeing in the Crypto++ library. After setting up the machine and running an
apt-get install for some build tools I noticed Python was failing:
Fatal Python error
Jeffrey Walton added the comment:
On Tue, Sep 11, 2018 at 8:26 PM, STINNER Victor wrote:
>
> STINNER Victor added the comment:
>
>> newsize <<= 1; // The largest possible value is PY_SSIZE_T_MAX + 1.
>
> Previously, there was a explicitly check for er
Jeffrey Walton added the comment:
I know this is a bit late but I wanted to share...
OpenCSW has a build farm with Solaris machines and Sparc hardware. The farm
provides x86 and Sparc machines with Solaris 9 through 11.
I believe OpenCSW operates in the same spirit as GCC compile farm
Jeffrey Walton added the comment:
I know this is a bit late but I wanted to share...
OpenCSW has a build farm with Solaris machines and Sparc hardware. The farm
provides x86 and Sparc machines with Solaris 9 through 11.
I believe OpenCSW operates in the same spirit as GCC compile farm
Jeffrey Walton added the comment:
On Tue, Jul 26, 2016 at 4:31 AM, Martin Panter <rep...@bugs.python.org> wrote:
>
> Martin Panter added the comment:
>
> The Modules/main.c cases are not errors. They are just long strings defined
> as static constants, rather than litera
Jeffrey Walton added the comment:
> Has this sort of thing been done in other projects?
Yes.
If you are using C, you can use safe_iop. Android uses it for safer
integer operations. If you are using C++, you can use David LeBlanc's
SafeInt class. Microsoft uses it for safer inter operati
New submission from Jeffrey Walton:
The Python wiki page on SSL states (https://wiki.python.org/moin/SSL):
To validate that a certificate matches requested site,
you need to check commonName field in the subject of
the certificate.
I don't think its quite correct.
Both the IETF
Jeffrey Walton added the comment:
there's not much point in reporting bugs here about it.
Oh, sorry about that.
That page's contents look very outdated, by the way.
Yeah, there's a few opportunities for improvement.
--
___
Python tracker rep
New submission from Jeffrey Walton:
Python 3.4.0 downloaded from website
(https://www.python.org/download/releases/3.4.0/).
Objects/dictobject.c:756:5: runtime error: left shift of negative value -2
Objects/funcobject.c:907:5: runtime error: left shift of negative value -2
Objects/funcobject.c
New submission from Jeffrey Walton:
Updated. Its a lot easier to identify gaps and update once its seen with
formatting.
* Added info on interpreting results
* Added info on flags and CFLAGS, CXXFLAGS, CC, and CXX
* Added info on Mac OS X
* Asan - ASan, UBsan - UBSan
* Fixed UBSan example
Jeffrey Walton added the comment:
Contributor license was signed, though I don't consider my self a contributor.
The devs are making the real contributions.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20965
New submission from Jeffrey Walton:
Python's code is crisp and sharp. From a software design perspective, I don't
see a lot of room for improvement. However, looking at some of the issues
flagged by Clang sanitizers and existing bug reports, I think the project has a
couple of small
Jeffrey Walton added the comment:
Also see http://bugs.python.org/issue20944 for suggestions to identify the
offending code.
--
nosy: +Jeffrey.Walton
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1621
Jeffrey Walton added the comment:
On Sun, Mar 16, 2014 at 11:12 AM, R. David Murray
rep...@bugs.python.org wrote:
R. David Murray added the comment:
We already have Coverty scan in place, and were in fact featured by them
for our code quality. Currently Christian Heimes is the lead
New submission from Jeffrey Walton:
$ hg id
3736bf94535c+ tip
Forgive me if you were aware of these.
/usr/bin/gcc -pthread -fPIC -Wno-unused-result
-Werror=declaration-after-statement -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -fno-common -Wstrict-overflow -Wformat=2 -Wformat
New submission from Jeffrey Walton:
$ hg id
3736bf94535c+ tip
-Wformat=2 -Wformat-security are useful for detecting possible security related
bugs. Compiling with the two options produced a few hits in the source code.
/usr/bin/gcc -pthread -c -Wno-unused-result -Werror=declaration-after
Jeffrey Walton added the comment:
If interested, I think the warnings can be selectively turned off:
#if defined (__GNUC__) ((__GNUC__ == 4 __GNUC_MINOR__ = 6) || (__GNUC__
= 5))
# pragma GCC diagnostic push
# pragma GCC diagnostic ignored -Wformat-security
#endif
unicode_fromformat_arg
Jeffrey Walton added the comment:
#if defined (__GNUC__) ((__GNUC__ == 4 __GNUC_MINOR__ = 6) ||
(__GNUC__ = 5))
# pragma GCC diagnostic push
# pragma GCC diagnostic ignored -Wformat-security
#endif
My bad... -Wformat-nonliteral
--
___
Python
New submission from Jeffrey Walton:
$ hg id
3736bf94535c+ tip
A standard Python build does not take a proactive approach to integrating with
platform security measures. Attepting to add the measures results in a failed
build.
For example:
export CC=/usr/bin/gcc
export CXX=/usr/bin/g
Jeffrey Walton added the comment:
$ checksec.sh --file ./python
RELRO STACK CANARY NXPIE RPATH
RUNPATH FILE
Full RELRO Canary found NX enabledPIE enabled No RPATH No
RUNPATH ./python
Here's what a standard Python
Jeffrey Walton added the comment:
It probably is an OpenSSL bug but the declaration doesn't help us.
It's not the first time Python has to work around OpenSSL, e.g. #18709.
Sorry to dig up an old issue. But here's some reading on it if interested.
Ben Laurire pushed a patch to mix in PID
New submission from Jeffrey Walton:
Some versions of OpenSSL use the RDRAND engine by default. The versions include
openssl-1.0.1-beta1 through openssl-1.0.1f.
RDRAND has taken some criticism because its essentially unaudited and it could
be spiked like the Dual-EC generator
(http
Jeffrey Walton added the comment:
This might be relevant. It showed up while building Python 3.3.5 from sources.
/usr/local/bin/clang -fsanitize=undefined -fPIC -Wno-unused-result -DNDEBUG -g
-fwrapv -O3 -Wall -Wstrict-prototypes -I./Include -I. -IInclude
-I/usr/local/include -IPython-3.3.5
New submission from Jeffrey Walton:
This came from Python 3.3.5 downloaded from thePython download page ().
The issue occurred while compiling with Clang 3.4 using the address sanitizer
(-fsanitize=address)
/usr/local/bin/clang -fsanitize=address -Xlinker -export-dynamic -o python
Modules
New submission from Jeffrey Walton:
From Python head in mercurial.
When building Python under Clang's sanitizers, we provide a couple of flags to
instrument binaries with the sanitizers. For example:
export CC=/usr/local/bin/clang
export CXX=/usr/local/bin/clang++
export CFLAGS=-g3 -fsanitize
Jeffrey Walton added the comment:
And:
Modules/_testembed: Modules/_testembed.o $(LIBRARY) $(LDLIBRARY) $(PY3LIBRARY)
$(LINKCC) -g3 -fsanitize=address $(PY_LDFLAGS) $(LINKFORSHARED) -o $@
Modules/_testembed.o $(BLDLIBRARY) $(LIBS) $(MODLIBS) $(SYSLIBS) $(LDLAST
Jeffrey Walton added the comment:
And:
Modules/_freeze_importlib: Modules/_freeze_importlib.o
$(LIBRARY_OBJS_OMIT_FROZEN)
$(LINKCC) -g3 -fsanitize=address $(PY_LDFLAGS) -o $@
Modules/_freeze_importlib.o $(LIBRARY_OBJS_OMIT_FROZEN) $(LIBS) $(MODLIBS)
$(SYSLIBS) $(LDLAST
New submission from Jeffrey Walton:
From Python head in mercurial:
$ hg id
7ce22d0899e4+ tip
[118/389/1] test_strftime
==11587==WARNING: AddressSanitizer failed to allocate 0x7fff bytes
==11587==AddressSanitizer's allocator is terminating the process instead of
returning 0
New submission from Jeffrey Walton:
From Python head in mercurial:
$ hg id
7ce22d0899e4+ tip
Exporting set allocator_may_return_null=1 for Clang might tickle this issue.
Without the export, this test did not fail
Jeffrey Walton added the comment:
This does not look quite right from Modules/sockewtmodule.c.
/* Fill in an iovec for each item, and save the Py_buffer
structs to release afterwards. */
if (nitems 0 ((iovs = PyMem_New(struct iovec, nitems)) == NULL
New submission from Jeffrey Walton:
Test 240 also suffers from a buffer overflow on sock_recvmsg_guts.
Test 240 is the test that follows 239, and 239 is [239/389/2] test_unittest.
(I don't believe the message for 239 has flushed
New submission from Jeffrey Walton:
pytime.c:184: runtime error: value -1e+200 is outside the range of
representable values of type 'long'
and
pytime.c:218: runtime error: value -1e+200 is outside the range of
representable values of type 'long'
It appears the cast on 'intpart
Jeffrey Walton added the comment:
On Sat, Mar 15, 2014 at 6:34 PM, Benjamin Peterson
rep...@bugs.python.org wrote:
Benjamin Peterson added the comment:
Just use LDFLAGS.
Yeah, I tried that and broke the sanitizer:
https://groups.google.com/d/msg/address-sanitizer/cu2WoD1Bwx8/zUoY9GH7oHkJ
Jeffrey Walton added the comment:
On Sat, Mar 15, 2014 at 7:11 PM, Benjamin Peterson
rep...@bugs.python.org wrote:
Benjamin Peterson added the comment:
CFLAGS=-g3 -fsanitize=address LDFLAGS=-fsanitize=address ./configure
--with-system-expat make -j4
works for me.
Oh,my bad. I thought
New submission from Jeffrey Walton:
Downloaded Python-3.4.0rc3. Compiled with Clang 3.4, added -fsanitzie=undefined
to CFLAGS. Ran 'make' and 'make check'.
Lots of issues, many are duplicates (see below). One or more of these issues
might be the reason for `-fwrapv`.
This fellow from
Changes by Jeffrey Walton noloa...@gmail.com:
Added file: http://bugs.python.org/file34426/python-3-4-make-test.txt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20929
Jeffrey Walton added the comment:
Defining PY_FORMAT_LONG_LONG had a side effect:
/usr/local/bin/clang -c -Wno-unused-result -Werror=declaration-after-statement
-DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -g3 -fsanitize=undefined
-DPY_FORMAT_LONG_LONG=1 -g3 -fsanitize=undefined
Jeffrey Walton added the comment:
Could you check if the current default branch of mercurial fixes the
problems?
Checkout is complete. Working through a build now.
Could you look at http://bugs.python.org/issue20930 and advise on the best way
to proceed
Jeffrey Walton added the comment:
The big list of issues earlier has been parred down to the following after
`make`:
Objects/longobject.c:40:42: runtime error: index -3 out of bounds for type
'PyLongObject [262]'
Objects/listobject.c:2046:22: runtime error: index 623 out of bounds for type
Jeffrey Walton added the comment:
What branch are you building now?
Python 3.5 from `hg clone http://hg.python.org/cpython`.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20929
Jeffrey Walton added the comment:
Updated title to reflect Python 3.4-RC3.
--
title: Undefined behavior flagged by Clang 3.4 - Undefined behavior flagged by
Clang 3.4 (Python 3.4-RC3)
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Jeffrey Walton added the comment:
Well, that's 3.4.1 atm.
My bad. I managed to download a file named Python-3.4.0rc3.tgz this morning
(the tarball is still in my downloads). I'm not sure from where since
http://www.python.org/download/ does not have
New submission from Jeffrey Walton:
Checked out Python-3.5 from mercurial. Compiled with Clang 3.4, added
-fsanitzie=undefined to CFLAGS. Ran 'make' and 'make check'. A few issues
during `make`:
Objects/longobject.c:40:42: runtime error: index -3 out of bounds for type
'PyLongObject [262
Changes by Jeffrey Walton noloa...@gmail.com:
Added file: http://bugs.python.org/file34429/python-3.5-make-test.txt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20932
Jeffrey Walton added the comment:
Also see http://bugs.python.org/issue20932.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20929
Jeffrey Walton added the comment:
Pulled the latest after BP cleared some more runtime errors:
$ hg summary
parent: 89662:7ce22d0899e4 tip
merge 3.3
branch: default
commit: 2 modified
update: (current)
Misaligned accesses dominate with over 11K:
$ cat python-3.5-make-test.txt
Jeffrey Walton added the comment:
This is just the same as #20929, I believe?
I think most of the issues in the 20929 report (Python 3.4-RC3) are present in
this report. But under this report, I can re-test as you check in the fixes.
(Python 3.4-RC3 is fixed in time from my perspective
Jeffrey Walton added the comment:
Here's another one I missed. The first is a problem due to silent truncation
when casting from the double 3.40282e+38 to a float (or Clang is wrong).
[ 10/389] test_struct
/home/jwalton/Desktop/cpython-checkout/Objects/floatobject.c:2028: runtime
error: value
Jeffrey Walton added the comment:
On Fri, Mar 14, 2014 at 10:28 PM, Benjamin Peterson
rep...@bugs.python.org wrote:
Benjamin Peterson added the comment:
Well, that's 3.4.1 atm.
Here's why I got that stale version:
https://www.google.com/search?q=download+python+3.4. The first hit is
RC3
49 matches
Mail list logo
