Dave Malcolm added the comment:
I've refreshed this patch against the latest version of the code in hg.
In an attempt to make it easier to review, I've split it up into four (so far)
thematic patches, which apply in sequence.
--
Added file:
http://bugs.python.org/file
Changes by Dave Malcolm :
Added file:
http://bugs.python.org/file23173/0002-Add-error-handling-to-initialization-of-_hashlib.patch
___
Python tracker
<http://bugs.python.org/issue9
Changes by Dave Malcolm :
Added file:
http://bugs.python.org/file23174/0003-Add-optional-usedforsecurity-argument-in-various-pla.patch
___
Python tracker
<http://bugs.python.org/issue9
Changes by Dave Malcolm :
Added file:
http://bugs.python.org/file23175/0004-_hashlib-Add-selftest-for-FIPS-mode-and-usedforsecur.patch
___
Python tracker
<http://bugs.python.org/issue9
Dave Malcolm added the comment:
[and yes, I used git to generate the 4 patches; sorry ]
--
___
Python tracker
<http://bugs.python.org/issue9216>
___
___
Pytho
Dave Malcolm added the comment:
The cumulative effect of the above patches (to _hashlib) are equivalent to what
I've applied downstream to python 2 in RHEL 6.0 and Fedora 17 onwards, and
python 3 in Fedora 17 onwards.
In those environments I've additionally patched hashlib t
Dave Malcolm added the comment:
> >> - running Python in gdb
> > This is somewhat orthogonal, but the devguide/gdb page doesn't say how to
> > start running Python
> > in gdb (it might be obvious to people used to use gdb, but it should still
> > be menti
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue13390>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Dave Malcolm :
On ppc64, on this box, with glibc-2.14.90-19.ppc64, test_cmath fails with:
==
FAIL: test_specific_values (test.test_cmath.CMathTests
Dave Malcolm added the comment:
Reported in glibc's bug tracker as:
http://sourceware.org/bugzilla/show_bug.cgi?id=13472
--
___
Python tracker
<http://bugs.python.org/is
Dave Malcolm added the comment:
The glibc bug has been fixed in that project's git repo:
http://repo.or.cz/w/glibc.git/commit/850fb039cec802072f70ed9763927881bbbf639c
--
title: test_cmath fails on ppc with glibc-2.14.90 due to optimized
architecture-specific "hypot"
Dave Malcolm added the comment:
I agree. I filed this here in case anyone else ran into it, but given that
this is really a glibc bug (now fixed), I'm closing this out as "won't fix".
--
resolution: -> wont fix
status: open -> closed
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue13703>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue10527>
___
___
Python-bugs-list mailing list
Unsubscribe:
Dave Malcolm added the comment:
The analogous code within Modules/selectmodule.c uses
#ifdef HAVE_POLL
to guard the poll-using code, to support non-Windows platforms that don't have
"poll".
Presumably a patch for this sho
Dave Malcolm added the comment:
Also, I see that Modules/selectmodule.c has some painful-looking workarounds
involving "HAVE_BROKEN_POLL", which presumably would also be applicable here.
--
___
Python tracker
<http://bugs.python.o
Dave Malcolm added the comment:
[for reference: issue 11743 covered Antoine's rewrite of the connection class
to be pure python, for 3.3 (re msg138310)]
--
___
Python tracker
<http://bugs.python.org/is
New submission from Dave Malcolm :
test_gdb.py fails when builddir != srcdir: the regex tries to match lines like
this:
#0 builtin_id (self=, v=()) at
../Python/bltinmodule.c:919
but isn't expecting the "../" before the "Python/bltinmodule.c"
2.7 uses a different
Dave Malcolm added the comment:
FWIW, I've filed a bug about this issue for Fedora 15's python3 package here:
https://bugzilla.redhat.com/show_bug.cgi?id=722578
Looks like this has led to an extra .pyc in the old location for every Python 3
.py file in Fedora 15's variou
New submission from Dave Malcolm :
I'm attaching patches to handle some more "events" in the gdb7 debugging hooks
for CPython (aka Tools/gdb/libpython.py).
Currently, the hooks only care about C frames that are the bytecode interpreter
(i.e. PyEval_EvalFrameEx)
This pat
Changes by Dave Malcolm :
--
keywords: +patch
Added file: http://bugs.python.org/file22712/more-frames-in-gdb-hooks-py3k.patch
___
Python tracker
<http://bugs.python.org/issue12
Dave Malcolm added the comment:
(On 2.7, I needed import_site=True to get the new tests to work from a fresh
build: "import time" wasn't being found otherwise)
--
Added file: http://bugs.python.org/file22713/more-frames-in-gdb-
Dave Malcolm added the comment:
Another datapoint:
For Fedora 16, I haven't done any downstream patching (so far), because we
hadn't run into any downstream problems.
I did some digging into why we're _not_ experiencing issues.
Currently for Fedora 16, we're shipping ker
Dave Malcolm added the comment:
Note that PyPy is also affected by this issue; see
https://bugs.pypy.org/issue832
For CPython, I'm of the opinion that:
- the final digit of sys.platform as-is for "linux*" is effectively
meaningless
- that no code should be relying on the
New submission from Dave Malcolm :
On 64-bit PPC builds configured --with-tsc, Python segfaults within the first
function call in the bytecode interpreter.
Upon investigation this is due to this code in Python/ceval.c:
32 typedef unsigned long long uint64;
33
34 /* PowerPC
New submission from Dave Malcolm :
test_site.py has a couple of assertions of the form
self.assertTrue(len(foo), some number)
which appear to be incorrect, and should read:
self.assertEqual(len(foo), some number)
or assertEquals (that file uses both methods).
r76047 fixed some of these
Dave Malcolm added the comment:
Hopefully actually attaching the patch this time
I've used assertEqual in the lines I've touched. I haven't touched the other
lines, in order to isolate the semantic fix from the stylistic one.
--
Added file: http://bugs.python.org/file
New submission from Dave Malcolm :
runtests.sh -x fails to work with more than two tests; for example, running:
$ ./runtests.sh -x test_httplib test_http_cookies test_dl
erroneously runs test_dl
By default, "sed -e s" only substitutes the first match - the invocations
within runtes
Dave Malcolm added the comment:
FWIW it works with two args, but adding the third fails; echoing PAT indicates
the generated regex is missing the "|" separator:
^(test_httplib|test_http_cookies test_dl)$
--
___
Python trac
Dave Malcolm added the comment:
Looks like a dup of issue 4835
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue9629>
___
___
Python-bugs-list m
Changes by Dave Malcolm :
--
resolution: -> duplicate
status: open -> closed
superseder: -> SIZEOF_SOCKET_T not defined
___
Python tracker
<http://bugs.python.o
Dave Malcolm added the comment:
(BTW, the versioning seems slightly misleading: "(Red Hat 4.1.0-3)" refers to
the version of GCC, not of the operating system.
You appear to be running gcc-4.1.0-3, which I believe was shipped in Fedora
Core 5.
Updating "title" metadata of
New submission from Dave Malcolm :
It's sometimes useful to be able to programatically inject a breakpoint when
debugging CPython.
For example, sometimes you want a conditional breakpoint, but the logic
involved is too complex to be expressed in the debugger (e.g. runtime
complexi
Dave Malcolm added the comment:
> Note that when running on Linux when _not_ under a debugger, the
> default for SIGTRAP is to get a coredump:
> Trace/breakpoint trap (core dumped)
> so people should be strongly discouraged from adding these calls to
> their code.
Loo
New submission from Dave Malcolm :
With a clean build of release27-maint (r84317), test_dbm.py fails on ppc64 with
this error:
File "test_dbm.py", line 24, in test_keys
self.assert_(k in self.d)
AssertionError
I'm building gainst gdbm-1.8.0 (specifically, on a prerelease
Dave Malcolm added the comment:
Note to self: I'm tracking this one in RH's downstream tracker as:
https://bugzilla.redhat.com/show_bug.cgi?id=626756
--
___
Python tracker
<http://bugs.python.
Changes by Dave Malcolm :
--
nosy: dmalcolm
priority: normal
severity: normal
status: open
title: object.__basicsize__ is erroneously0
___
Python tracker
<http://bugs.python.org/issue9
New submission from Dave Malcolm :
On 64-bit bigendian machines (ppc64 and s390x), I'm seeing:
>>> print object.__basicsize__
0
(Discovered via a segfault in Jinja2 tries to use ctypes to manipulate
ob_refcnt of variables, and gets the wrong location, corrupting the objects
inst
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue8998>
___
___
Python-bugs-list mailing list
Unsubscribe:
Dave Malcolm added the comment:
> I think either of these is correct:
> - a UTF-8-encoded string
> - a string encoded in UTF-8
Possibly use the word "buffer" here, rather than "string", as "string" may
suggest the "str" type.
Or even: &
Dave Malcolm added the comment:
Tested with UCS4 gdb:
(gdb) python import sys; print hex(sys.maxunicode)
0x10
using latest py3k.
Works with both UCS2 and UCS4 builds of py3k
--
___
Python tracker
<http://bugs.python.org/issue9
Dave Malcolm added the comment:
where "works" means: all tests in test_gdb.py were run, and passed.
This was with a --with-pydebug-build in each case
--
___
Python tracker
<http://bugs.python.
Dave Malcolm added the comment:
One minor quibble with the patch:
In the line:
while i < field_length:
you're trusting that field_length has a sane value. If field_str points
somewhere readable, and field_length is huge (e.g. 0xfff), then gdb could
sit there for a while rea
Dave Malcolm added the comment:
"I don't think this" was of course a browser misfire; I meant to type "I don't
think this should block committing this fix"
--
___
Python tracker
<
Dave Malcolm added the comment:
For reference, the patch that I'm currently applying to Fedora's build of
Python-3.2a1 can be seen at:
http://pkgs.fedoraproject.org/gitweb/?p=python3.git;a=blob_plain;f=python-3.2a1-debug-build.patch;hb=HEAD
It appears to be very similar to Matth
Dave Malcolm added the comment:
In reply to Barry A. Warsaw:
>@dmalcolm: I suspect you can reduce your diff for Python 3.2 now that PEP 3149
>has landed.
Yeah, the patch I linked to is against the 3.2a1 tarball; I hoped to regenerate
it for 3.2a2 but have been swamped thi
Dave Malcolm added the comment:
On Fri, 2010-09-17 at 23:11 +, Antoine Pitrou wrote:
> Antoine Pitrou added the comment:
>
> > How about nss? As a bonus, this would also avoid making more work for
> > Fedora (<http://fedoraproject.org/wiki/FedoraCryptoConsolidation&
Dave Malcolm added the comment:
I should note that I can't touch anything to do with Elliptic Curve crypto. I
don't know if I can comment on the reasons for that.
--
___
Python tracker
<http://bugs.python.
Dave Malcolm added the comment:
FWIW, one of my RH colleagues (John Dennis) has written a set of Python
bindings for NSS:
http://fedoraproject.org/wiki/Features/PythonNSS
(Though that seems to me to be a slightly different thing to a general-purpose
crypto lib that happens to be written
Dave Malcolm added the comment:
giampaolo: did you ever rewrite the patch?
For reference to other users:
http://code.google.com/p/pyftpdlib/source/browse/trunk/pyftpdlib/ftpserver.py
Note the complexity of the two handle_accept implementations in that file; both
of them begin:
try
New submission from Dave Malcolm :
test test_structmembers crashed -- :
string too long
Traceback (most recent call last):
File "/builddir/build/BUILD/Python-2.7/Lib/test/regrtest.py", line 863, in
runtest_inner
the_package = __import__(abstest, globals(), locals(), [])
File
Dave Malcolm added the comment:
Updated py3k version of patch.
Changes:
- renamed the probepoints:
"function__entry" -> "frame__entry"
"function__return" -> "frame__exit"
as I believe this better describes what these do
-
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue9675>
___
___
Python-bugs-list mailing list
Unsubscribe:
Dave Malcolm added the comment:
Thanks. The code in question is a wrapper to a security-sensitive library
(user-space SELinux code), hence the compilation warnings have been turned up
as much as possible.
The .c code in question is generated by SWIG, and that does indeed appear to be
Dave Malcolm added the comment:
It looks like this doesn't yet have any test cases.
You probably should invoke a child python process that crashes and examine the
output (perhaps running some/all of the examples in Lib/test/crashers ?); you
may want to "steal" some of the wr
Dave Malcolm added the comment:
One other concern: many OSes (e.g. Linux distributions) implement some kind of
system-wide crash-catching utility; for example in Fedora we have ABRT (
https://fedorahosted.org/abrt/wiki ).
I'm not sure yet exactly how these are implemented, but we'
Dave Malcolm added the comment:
Updated version of patch attached (against py3k; r85426)
I've changed the names back to "function__entry" and "function__return".
--
___
Python tracker
<http
Dave Malcolm added the comment:
> About SIGBUS: I don't know this signal. Is it used on Linux? If not, on
> which OS is it used?
Yes, IIRC typically you'll only see it on RISC CPUs that require instructions
to be word-aligned; you typically see it if the program counter ju
Dave Malcolm added the comment:
I notice this issue is in stage "unit test needed".
It's not clear to me how to add a unit test for this: one idea I had is to
create a broken module in some subdir somewhere, and invoke "pydoc -k" as a
subprocess with PYTHONPATH co
Dave Malcolm added the comment:
Summarizing IRC discussion:
Tested on Fedora 13 x86_64 with:
--enable-shared --with-wide-unicode
and with confdir != srcdir with:
../configure --enable-shared --with-wide-unicode --with-pydebug
Mostly working but, test_distutils fails:
test_get_outputs
New submission from Dave Malcolm :
I'm attempting to fix up the build in my Fedora/RHEL packages of Python to
preserve timestamps of .py files as far as possible during the build, so that
.pyc/.pyo files end up with predictable embedded mtime values and thus
predictable hashes.
Am atta
Dave Malcolm added the comment:
Updated version of the patch; this ought to contain Include/pydtrace.d:
$ diffstat /tmp/py3k-add-systemtap-2010-10-25.patch
Include/pydtrace.d | 10
Lib/test/test_systemtap.py | 89 ++
Makefile.pre.in| 10
Python/ceval.c
Dave Malcolm added the comment:
Updated patch, removing the FIXMEs, and slightly reworking the test code.
I've wrapped the whole of get_frame_marker_info with a
PyErr_Fetch/PyErr_Restore pair: the PyUnicode_AsUTF8String calls could fail
with a MemoryError, and we don't want to c
Dave Malcolm added the comment:
> It would be better to generate the sample dynamically, so that users
> with an incompatible locale or filesystem aren't prevented from checking
> out the source.
Thanks: am attaching updated patch: I've removed
Lib/test/systemtap_sample_☠.p
Dave Malcolm added the comment:
I should note that I've only ever been testing this with SystemTap, on Linux.
I don't have a box with DTrace, and I've never directly used it. I wouldn't
today be able to diagnose a buildbot failure related to DTrace (I believe I
would
New submission from Dave Malcolm :
We were chatting on #python-dev on possible ways of testing the correct
handling of "MemoryError".
Attached is one idea: adding a sys._inject_malloc_failure() hook, letting you
inject a memory-allocation (or reallocation) failure some number of a
Dave Malcolm added the comment:
Attached is a new approach to doing this, based on "Out-Of-Memory Testing"
within http://sqlite.org/testing.html
This reads environment variables, and injects a fault at the given value of
"serialno", and (optionally) ongoing failures afte
Dave Malcolm added the comment:
One possible use for this: mark the "str" buffers of PyUnicodeObject instances
when demarshalling docstrings from disk; in theory these ought not to change,
and can be quite large: the bulk of the memory overhead is stored in a separate
allocatio
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue1346238>
___
___
Python-bugs-list mailing list
Unsubscribe:
Dave Malcolm added the comment:
Adding updated version of patch, which adds documentation to sys.rst and adds a
unit test.
I'm a little wary of this: it seems useful but also too much like a
self-destruct button for my taste.
--
Added file:
http://bugs.python.org/file19457/py3
Dave Malcolm added the comment:
I renamed it from sys.breakpoint to sys._breakpoint, since this is
CPython-specific
--
title: Add Py_BREAKPOINT and sys.breakpoint hooks -> Add Py_BREAKPOINT and
sys._breakpoint hooks
___
Python tracker
&l
New submission from Dave Malcolm :
Issue 5793 rationalized all usage of C "character" handling to use
"Py_"-prefixed locale-unaware macros, at the "char" level.
In particular, this comment was added in two places to Include/bytes_methods.h
in r72044:
http://svn.p
Changes by Dave Malcolm :
--
title: Remove -> Remove deprecated C "character" handling macros ISUPPER() etc
___
Python tracker
<http://bugs.pytho
Dave Malcolm added the comment:
Thanks for reviewing.
If I'm reading things correctly, the ISUPPER et al macros were added in 2.6 and
3.0, and deprecated in 2.7 and 3.1.
Tested with a full run of "-m test.regrtest -uall" here (x86_64 Fedora 13),
with both 2-byte and 4-b
Dave Malcolm added the comment:
Committed to py3k in r86210
--
___
Python tracker
<http://bugs.python.org/issue10288>
___
___
Python-bugs-list mailing list
Unsub
Dave Malcolm added the comment:
FWIW, I'm working on fixing up the this patch to work against py3k; I'm
assuming there's still interest in the AST visitor + specific optimization
passes approach.
--
___
Python tracker
<http
Dave Malcolm added the comment:
Seems to relate to this gdb feature:
http://sourceware.org/ml/gdb-patches/2005-05/msg00637.html
Barry: is your ~/.gdbinit world writable?
I can cook up a patch to ignore such warnings
--
___
Python tracker
<h
Dave Malcolm added the comment:
Alternatively, it looks like having it owned by another user would do this.
For curiosity's sake, what's the output of:
ls -al /home/barry/.gdbinit
on that buildbot?
Given that it's a security warning, should this simply be treated as
miscon
Dave Malcolm added the comment:
I've been working on this against the py3k branch. I'm attaching what I've got
so far.
I foolishly didn't check the tlee-ast-optimize branch, instead using file6850
as a base.
Rune Holm/titanstar, I assume you've signed a PSF contri
Dave Malcolm added the comment:
Another optimization idea: detect local dictionaries that are only ever used in
non-mutating ways, and convert them to constants, rather than rebuilding the
dict from scratch each time.
See e.g. htmlparser.py:adjustSVGAttributes etc within the bm_html5lib
Dave Malcolm added the comment:
Closing "won't fix", since this was misconfiguration; filtering out such
warnings might mask a security issue.
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bu
New submission from Dave Malcolm :
In various places within the generated Python/Python-ast.c, error handling
generates a repr() and raises exceptions accordingly.
Currently in py3k the generated code uses PyBytes_AS_STRING() on the repr. My
understanding is that repr() should be a
Dave Malcolm added the comment:
The attached patch:
- extends the ast error-handling selftest with code that triggers this crash
(on unpatched code)
- fixes Parser/asdl_c.py to generate code using _PyUnicode_AS_STRING instead
- contains the generated changes to Python/Python-ast.c
FWIW
Changes by Dave Malcolm :
--
nosy: +benjamin.peterson, brett.cannon, georg.brandl, ncoghlan
___
Python tracker
<http://bugs.python.org/issue10391>
___
___
Pytho
New submission from Dave Malcolm :
In msg#120541 of issue#1346238 Raymond suggested to "aim high", so here goes...
I'm opening this as a separate bug as it's a very different approach to the
patches in that bug; adding those on the nosy list for that bug. Sorry in
ad
Changes by Dave Malcolm :
Added file: http://bugs.python.org/file19584/before.png
___
Python tracker
<http://bugs.python.org/issue10399>
___
___
Python-bugs-list mailin
Changes by Dave Malcolm :
Added file: http://bugs.python.org/file19585/after.png
___
Python tracker
<http://bugs.python.org/issue10399>
___
___
Python-bugs-list mailin
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue10924>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue11410>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Dave Malcolm :
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue9263>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Dave Malcolm :
--
resolution: -> accepted
stage: patch review -> committed/rejected
status: open -> closed
versions: -Python 3.3
___
Python tracker
<http://bugs.python.or
Changes by Dave Malcolm :
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue9635>
___
___
Python-bugs-list mailing list
Unsubscribe:
Dave Malcolm added the comment:
Various thoughts/nitpicking:
- is it possible to indicate with a coding convention (e.g. comments) which
parts of the code are intended to be called from a signal handler? It seems
worth making this explicit. Or perhaps put it all in one file?
- within
New submission from Dave Malcolm :
With hg/mercurial 0.9.3, the build of CPython fails with this error:
gcc -pthread -c -fno-strict-aliasing -g -O0 -Wall -Wstrict-prototypes-I.
-IInclude -I./Include-DPy_BUILD_CORE \
-DHGVERSION="\"`LC_ALL=
Dave Malcolm added the comment:
Works OK with mercurial 1.3.1
(specifically, this is on a RHEL5 box, using mercurial-1.3.1-3.el5.i386.rpm
from EPEL5)
Closing this out, and changing title to help people searching for this. Not
sure of the exact version of mercurial that's req
Dave Malcolm added the comment:
I tried again, and I'm still able to reproduce this bug on a RHEL5 box with
cpython --with-pydebug as of a recent checkout (69030:00217100b9e7 as it
happens):
$ ./python -c "import multiprocessing.managers ; mpp = multiprocessing.Po
Dave Malcolm added the comment:
This is indeed looking like it's RHEL-specific.
I was about to close it out as a duplicate of issue 10517, but I'm wondering
why Brian chose to open it as a separate bug.
--
___
Python trac
Dave Malcolm added the comment:
jcea: I notice that on 2011-02-22 you made these changes:
assignee: dmalcolm -> dino.viehland
nosy: +dino.viehland
versions: +Python 3.3 -Python 3.2
Did you mean to change the assignee, or was this an accid
New submission from Dave Malcolm :
For Python 2 (here with 2.7.1):
$ python -c 'import locale; locale.setlocale(locale.LC_ALL, "tr_TR.UTF-8");
import decimal'
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib64/python2.7/decimal.py
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue11845>
___
___
Python-bugs-list mailing list
Unsubscribe:
1 - 100 of 417 matches
Mail list logo
