Dave Malcolm added the comment:
I think when I wrote this I was over-optimistically thinking that we could just
add more patterns, but if it's becoming a pain, then your approach looks good
to me.
--
nosy: +dmalcolm
___
Python tracker
&
Dave Malcolm added the comment:
Thanks!
--
___
Python tracker
<https://bugs.python.org/issue9263>
___
___
Python-bugs-list mailing list
Unsubscribe:
Dave Malcolm added the comment:
On Fri, 2018-02-23 at 00:16 +, Cheryl Sabella wrote:
> Cheryl Sabella added the comment:
>
> Did PEP553 make this issue obsolete?
I *think* they have slightly different scope: if I'm reading it right,
PEP553 is about injecting a breakpoint i
Dave Malcolm added the comment:
The problem is that there are so many variables:
* which version of which compiler
* optimization flags
* which version of gdb
* which CPU architecture
etc (and the compiler and/or gdb could be carrying patches from downstream
distributors...)
All of these can
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue21590>
___
___
Python-bugs-list mailing list
Unsubscribe:
Dave Malcolm added the comment:
On Mon, 2014-05-19 at 14:15 +, Dave Malcolm wrote:
> Dave Malcolm added the comment:
>
> On Mon, 2014-05-19 at 11:10 +, Bohuslav "Slavek" Kabrda wrote:
> > Bohuslav "Slavek" Kabrda added the comment:
> >
> >
Dave Malcolm added the comment:
On Mon, 2014-05-19 at 11:10 +, Bohuslav "Slavek" Kabrda wrote:
> Bohuslav "Slavek" Kabrda added the comment:
>
> Hi,
> I'd like to take this over after Dave Malcolm. I don't see any issues that
> haven't be
Dave Malcolm added the comment:
On Tue, 2014-01-07 at 16:30 +, Yury V. Zaytsev wrote:
> Yury V. Zaytsev added the comment:
>
> After lots of fiddling, I can tell you what's wrong with the macro:
> apparently it's a compiler bug, visible at -O2 and disappearing at -O1
Dave Malcolm added the comment:
[FWIW, this looks similar to an issue I ran into on Fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=913732
which was due to a mismatch between the kernel headers on the system vs the
actually running kernel. I patched around it there with a downstream-only
Dave Malcolm added the comment:
FWIW, I feel that it's worth just expecting failures with an *optimized* build:
with an optimizing compiler, there's likely to always be some program counter
location where the debugger is going to get confused for some variables. Given
umpteen
Dave Malcolm added the comment:
Antoine's patch looks reasonable to me, FWIW.
--
___
Python tracker
<http://bugs.python.org/issue18772>
___
___
Python-bugs-l
Dave Malcolm added the comment:
On Mon, 2013-07-29 at 14:01 +, Ronald Oussoren wrote:
> Ronald Oussoren added the comment:
>
> The attached patch for the benchmark README.txt should document the status
> quo.
>
> --
> Added file: http://bugs.python.org/file3
Dave Malcolm added the comment:
pmuldoon: did you truncate the output of bt? (or did the superior gdb you're
using do this behind the scenes? I know you hack on gdb itself, and this looks
a superior gdb debugging an inferior gdb).
The reason for this error:
Python Exception (2
Changes by Dave Malcolm :
--
resolution: -> fixed
stage: commit review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Dave Malcolm added the comment:
Can you try this candidate fix?
--
Added file: http://bugs.python.org/file30007/possible-fix.patch
___
Python tracker
<http://bugs.python.org/issue17
Dave Malcolm added the comment:
Looking at test_gdb.out, the issue is that the threads waiting for the GIL have
e.g. this at the top of their backtrace:
Thread 2 (Thread 0x3fffb14af200 (LWP 37119)):
#0 0x008075181ea8 in __pthread_cond_timedwait (cond=0x103ea140 ,
mutex=0x103ea170
Dave Malcolm added the comment:
Thanks. I can't see from that output what's going wrong.
Can you apply the following patch, which (I hope) will print more detailed info
where the failure happens.
--
keywords: +patch
Added file: http://bugs.python.org/file30005
Dave Malcolm added the comment:
Is this an optimized or a debug build? (aka --with-pydebug)
What are the optimization flags passed to the C compiler?
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue17
Dave Malcolm added the comment:
On Wed, 2013-04-24 at 10:48 +, Alex Leach wrote:
> Alex Leach added the comment:
>
> I don't think I can tell you anything you don't know already, but ...
>
> On Tue, 23 Apr 2013 19:38:18 +0100, Dave Malcolm
> wrote:
&g
Dave Malcolm added the comment:
BTW, is that GCC format checking code available anywhere?
Am I right in thinking that it was an out-of-tree patch to GCC, from the
pre-plugin days?
[My cpychecker code adds some similar checking, but it doesn't use this
attr
Dave Malcolm added the comment:
On Sat, 2013-04-20 at 21:25 +, Ned Deily wrote:
> Ned Deily added the comment:
>
> Dave, any reason this shouldn't go into the imminent 2.7.5 and 3.3.2 releases?
I was trying to think of one; the only reason I can think of is if there
are any
Dave Malcolm added the comment:
Thanks. Does upstream gdb have a plan dcoumented somewhere for how to deal
with all of the FOO-gdb.py files. Are they expected to be coded to the common
Python 2/3 subset?
--
___
Python tracker
<h
Dave Malcolm added the comment:
I didn't know that gdb supported embedding Python 3. Is this a set of patches
you're applying downstream, or an official gdb feature?
If so, it means everyone coding to the gdb API needs to somehow make their
FOO-gdb.py files be Python 3-
New submission from Dave Malcolm:
It appears that gcc's -Wformat warning changed from being on by default in gcc
4.7 and earlier to being off by default in gcc 4.8, needing to be enabled with
-Wformat (or -Wall), if I'm reading:
http://gcc.gnu.org/viewcvs/gcc?view=revision&r
New submission from Dave Malcolm:
Does the devguide document the benchmarking suite anywhere? I can't see it
anywhere in the index on http://docs.python.org/devguide/ and google doesn't
seem to show anything.
suggested content:
* how to run the benchmarks for a Python 2 impl
Dave Malcolm added the comment:
For reference, quoting PEP 3149:
>>> sysconfig.get_config_var('SO')
'.cpython-32mu.so'
--
nosy: +dmalcolm
___
Python tracker
<h
New submission from Dave Malcolm:
Within multiprocessing.connection, deliver_challenge() and
answer_challenge() use hmac for a challenge/response.
hmac implicitly defaults to using MD5.
MD5 should no longer be used for security purposes. See e.g.
http://www.kb.cert.org/vuls/id/836068
This
New submission from Dave Malcolm:
When running my refcount static analyzer [1] on a large corpus of real-world C
extension code for Python, I ran into the following construct in various places:
Py_XDECREF(PyObject_CallObject(callable, args));
This is bogus code: Py_XDECREF expands its
Dave Malcolm added the comment:
Minor bikeshedding/spelling nit: should
"_Py_AllocedBlocks"
be changed to
"_Py_AllocatedBlocks"
(and s/_Py_GetAllocedBlocks/_Py_GetAllocatedBlocks/)?
--
___
Python tracker
<http://bug
Changes by Dave Malcolm :
--
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue15516>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue16612>
___
___
Python-bugs-list mailing list
Unsubscribe:
Dave Malcolm added the comment:
In my Fedora Python packages I've been applying this patch:
http://pkgs.fedoraproject.org/cgit/python.git/plain/00156-gdb-autoload-safepath.patch
which uses this code fragment to detect if gdb has the autoload safe path code,
rather than trying to guess it
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue16191>
___
___
Python-bugs-list mailing list
Unsubscribe:
Dave Malcolm added the comment:
(patch added)
--
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue15778>
___
___
Python-bugs-list mai
Changes by Dave Malcolm :
--
keywords: +patch
Added file: http://bugs.python.org/file26988/fix-str-of-bogus-ImportError.patch
___
Python tracker
<http://bugs.python.org/issue15
Dave Malcolm added the comment:
Sorry, it's 6825fd9b00ed
--
___
Python tracker
<http://bugs.python.org/issue15778>
___
___
Python-bugs-list mailing list
New submission from Dave Malcolm:
In Python 3.2 and earlier:
>>> str(ImportError(b'foo'))
"b'foo'"
In Python 3.3:
>>> str(ImportError(b'foo'))
Traceback (most recent call last):
File "", line 1, in
TypeError: __str__ retu
Dave Malcolm added the comment:
On Thu, 2012-08-09 at 21:04 +, STINNER Victor wrote:
> STINNER Victor added the comment:
>
> Oh, I didn't realize that the documentation says that the default value is -1.
> http://docs.python.org/library/functions.html#__import__
>
Dave Malcolm added the comment:
(FWIW, this was observed when compiling pygobject-3.3.4 against Python-3.3.0b1)
--
___
Python tracker
<http://bugs.python.org/issue15
New submission from Dave Malcolm:
I've been testing various 3rd-party python code against 3.3b1, and see
ValueError: level must be >= 0
exceptions where C code is using PyImport_ImportModuleEx.
PyImport_ImportModuleEx reads as
63 #define PyImport_ImportModuleEx(n, g, l, f)
Dave Malcolm added the comment:
On Tue, 2010-11-02 at 17:25 +, Antoine Pitrou wrote:
> Antoine Pitrou added the comment:
>
> I would rename Py_BREAKPOINT to _Py_BREAKPOINT since we don't really want to
> support this. Also, why do you allow any arguments to sys._breakpoin
Changes by Dave Malcolm :
--
nosy: +teoliphant
___
Python tracker
<http://bugs.python.org/issue15540>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Dave Malcolm :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue15540>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Dave Malcolm :
--
nosy: +haypo, loewis
___
Python tracker
<http://bugs.python.org/issue15540>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Dave Malcolm :
Added file:
http://bugs.python.org/file26669/hack-out-test-against-MAX_UNICODE-from-cpython-3.3.patch
___
Python tracker
<http://bugs.python.org/issue15
New submission from Dave Malcolm:
I've been trying to get numpy working with Python 3.3, and to so I had to make
some changes to CPython - hence I'm posting this to the Python bug tracker.
numpy pokes at the insides of PyUnicodeObject in a few places and is thus
affected by t
Dave Malcolm added the comment:
Note to self: a messy way of forcing gdb to do the equivalent of a breakpoint
directly from Python is:
os.kill(os.getpid(), signal.SIGTRAP)
--
___
Python tracker
<http://bugs.python.org/issue9
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue15516>
___
___
Python-bugs-list mailing list
Unsubscribe:
Dave Malcolm added the comment:
I believe this was due to this line:
return self._gdbframe.name().startswith('pthread_cond_timedwait')
within is_waiting_for_gil(), and your gdb returned None for
self._gdbframe.name() for your build.
I've changed it to:
name = self._gdbfra
Dave Malcolm added the comment:
Fixes committed to 3.2 and default: RHEL 6.3 is now green for both branches.
Closing this bug out.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python track
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue15110>
___
___
Python-bugs-list mailing list
Unsubscribe:
Dave Malcolm added the comment:
(with the patch, it also continues to work on a test Fedora 15 box)
--
___
Python tracker
<http://bugs.python.org/issue14
Dave Malcolm added the comment:
The approach Nick suggests seems reasonable, but rpm.expandMacro isn't usable:
there's no guarantee that the machine has Python bindings for rpm installed
(especially not for the version of Python that we've just built).
However, we can get
Changes by Dave Malcolm :
--
keywords: -needs review
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Dave Malcolm added the comment:
I'm attaching an updated version of the patch; I hope there's still time before
Saturday to get it into 3.3
I found a bug in the configure script in the old patch: /usr/bin/dtrace was
required, even without requesting systemtap. I've fixed it
Dave Malcolm added the comment:
I'm able to reproduce this on a RHEL 6 box, and I did some investigating. The
stray .pyc files are indeed reported by "file" as "python 2.6 byte-compiled" so
yes, it's using /usr/bin/python to byte-compile them
On RHEL 6, with
Dave Malcolm added the comment:
Thanks. I too am wondering where the documentation should go. We currently
have several locations for documentation:
(1) the man page
(2) the "Doc" subdirectory aka docs.python.org
(3) various text files in the source tree, su
Changes by Dave Malcolm :
Removed file:
http://bugs.python.org/file25615/cpython-systemtap-2012-05-16-001.patch
___
Python tracker
<http://bugs.python.org/issue14
Changes by Dave Malcolm :
--
Removed message: http://bugs.python.org/msg160914
___
Python tracker
<http://bugs.python.org/issue14776>
___
___
Python-bugs-list m
Changes by Dave Malcolm :
--
Removed message: http://bugs.python.org/msg160913
___
Python tracker
<http://bugs.python.org/issue14776>
___
___
Python-bugs-list m
Dave Malcolm added the comment:
(Sorry about msg160913; looks like my initial email response took about an hour
to get through, and I'd subsequently commented using the webui form)
--
___
Python tracker
<http://bugs.python.org/is
Dave Malcolm added the comment:
On Wed, 2012-05-16 at 16:41 +, Antoine Pitrou wrote:
> Antoine Pitrou added the comment:
>
> I tried the patch under Mageia 1 and got the following failure:
>
> test_systemtap skipped -- Test systemtap script did not run; stderr was:
>
Dave Malcolm added the comment:
> I tried the patch under Mageia 1 and got the following failure:
Thanks. I'm attaching an updated patch which reworks test_systemtap so that
(a) it turns up the verbosity of stap invocations from "-v" to "-vv"
(b) it tests the &q
Dave Malcolm added the comment:
Oops; closing. Thanks.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Changes by Dave Malcolm :
--
nosy: +fche, scox
___
Python tracker
<http://bugs.python.org/issue14776>
___
___
Python-bugs-list mailing list
Unsubscribe:
Dave Malcolm added the comment:
Thanks. I'm attaching an updated version of the patch, wrapping all new C
entrypoints within a #ifndef Py_LIMITED_API
I also moved the existing _PyObject_DebugMallocStats() entrypoint to within a
#ifndef Py_LIMITED_API. As noted above, it is not docum
Dave Malcolm added the comment:
Updated version of the patch, using test.script_helper.assert_python_ok() and
adding a NEWS entry
--
Added file: http://bugs.python.org/file25579/add-debug-malloc-stats-v2.patch
___
Python tracker
<h
New submission from Dave Malcolm :
I'm attaching a patch which generalizes the at-exit PYTHONMALLOCSTATS memory
usage report, so that it's available in a regular build and can be triggered
from Python, by calling:
sys._debugmallocstats()
This can be useful when debugging me
Dave Malcolm added the comment:
Issue #13405 covers DTrace; I've taken the liberty of also opening issue #14776
to cover SystemTap. I hope that once one of these is in the tree it will be
easier to get the other one in.
--
___
Python tr
Changes by Dave Malcolm :
Added file:
http://bugs.python.org/file25540/devguide-systemtap-2012-05-11-001.patch
___
Python tracker
<http://bugs.python.org/issue14
Dave Malcolm added the comment:
Thanks Eric, Antoine and Mark.
I'm attaching two new patches: a replacement patch for cpython, and a new patch
for the devguide
I've moved the docs to the dev guide, starting a new "Debugging and
Instrumentation" section there.
Changes
Dave Malcolm added the comment:
I've refreshed my SystemTap patch, and opened a new issue, issue #14776 to
cover SystemTap.
Issue #4111 was originally opened on 2008-10-12 as "Add DTrace probes", and was
generalized on 2009-12-08 to "Add Systemtap/DTrace probes".
New submission from Dave Malcolm :
I'm attaching a patch which adds static markers for SystemTap for two probeable
events within CPython's bytecode interpreter, along with test cases and
documentation.
I'm hoping to get this merged for 3.3; is this PEP-worthy, or can this b
Dave Malcolm added the comment:
Note to self: workaround is to
rm ../../Lib/_sysconfigdata.py || make ../../Lib/_sysconfigdata.py
before running my tests in either configuration, to force the file to be
regenerated using what "make" thinks the se
New submission from Dave Malcolm :
When building from source, if I create multiple configuration directories and
build from there e.g.:
mkdir configs
cd configs
mkdir config-A
cd config-A
../../configure
make
cd ..
mkdir config-B
cd config-B
../../configure --enable-shared
make
cd ../config-A
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue14757>
___
___
Python-bugs-list mailing list
Unsubscribe:
Dave Malcolm added the comment:
Like passwd and group information, the shadow password entries are pulled
through libc's Name Service Switch and modules for it, depending on
configuration.
See "man nsswitch.conf".
Hence this is likely to be a configuration difference betwee
Dave Malcolm added the comment:
__os_install_post is defined within /usr/lib/rpm/redhat/macros and contains
this fragment:
/usr/lib/rpm/brp-python-bytecompile %{__python}
%{?_python_bytecompile_errors_terminate_build} \
Hence it will use %{__python} as the default when byte-compiling
Dave Malcolm added the comment:
As a post-processing step, rpmbuild will attempt to byte-compile any .py files
it encounters, and the results must be listed in the %files manifest. [1]
This is done by the script brp-python-bytecompile, which uses the compileall
module. However, my guess is
Dave Malcolm added the comment:
$ gdb --eval-command="break _PyRandom_Init" --eval-command="run"
--eval-command="print _Py_HashSecret" --eval-command="set
_Py_HashSecret.prefix=0xcdcdcd00" --eval-command="print _Py_HashSecret"
--eval-command
Dave Malcolm added the comment:
Thanks for filing this bug report.
I'm not seeing the equal hashes you describe.
I'm using this recipe to hardcode a specific prefix and print the hashes using
it:
$ gdb --eval-command="break _PyRandom_Init" --eval-command="ru
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue14621>
___
___
Python-bugs-list mailing list
Unsubscribe:
Dave Malcolm added the comment:
The originally attached patch is no good for the the 2.* branch, as it appears
that _testcapimodule.c will not become "ssize_t" safe in Python 2.*; see e.g.:
http://hg.python.org/cpython/rev/3ecddf168f1f
Am attaching a revised patch that I&
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue1>
___
___
Python-bugs-list mailing list
Unsubscribe:
Dave Malcolm added the comment:
It would appear that having:
[diff]
git = on
in ~/.hgrc breaks the rietveld integration, since "hg diff" then emits a diff
that doesn't identify the hg revision number, and hence the importer can't
de
Changes by Dave Malcolm :
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue13963>
___
___
Python-bugs-list mailing list
Unsubscribe:
Dave Malcolm added the comment:
Some notes from discussion with MvL at PyCon sprint:
The ideal is that:
- for any patch attached to an issue: the patch is uploaded to a Rietveld
instance colocated in the same db as Roundup (bugs.python.org)
- if it works, than a "review" link
Changes by Dave Malcolm :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue14234>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Dave Malcolm :
Expat 2.1.0 Beta was recently announced:
http://mail.libexpat.org/pipermail/expat-discuss/2012-March/002768.html
which contains (among other things) a fix for a hash-collision
denial-of-service attack (CVE-2012-0876)
I'm attaching a patch which mini
Changes by Dave Malcolm :
--
components: +Library (Lib)
type: -> enhancement
___
Python tracker
<http://bugs.python.org/issue14103>
___
___
Python-bugs-lis
Dave Malcolm added the comment:
jcea: BTW, will you be at PyCon US this year? if so, can we sprint on getting
the DTrace and SystemTap hooks into CPython in some form acceptable to the rest
of the CPython maintainers?
--
___
Python tracker
<h
Dave Malcolm added the comment:
Duplicate of issue 7732
--
resolution: -> duplicate
status: open -> closed
superseder: -> imp.find_module crashes Python if there exists a directory
named "__init__.py"
___
Python tracker
<
New submission from Dave Malcolm :
$ mkdir some_directory_ending_with_a.py
$ python -c "import imputil;
imputil.imp.find_module('some_directory_ending_with_a')"
*** glibc detected *** python: double free or corruption (!prev):
0x01589bf0 ***
Aborted
What
Changes by Dave Malcolm :
--
nosy: +dmalcolm
___
Python tracker
<http://bugs.python.org/issue14001>
___
___
Python-bugs-list mailing list
Unsubscribe:
Dave Malcolm added the comment:
I'm not quite sure how that would interact with the -R command-line
option for enabling randomization.
The changes to the docs in the latest patch clarifies the meaning of
what I've implemented (I hope).
My view is that we should simply e
New submission from Dave Malcolm :
I've been waiting for patch review of my work on
http://bugs.python.org/issue13703 only to discover that people *have* been
reviewing it.
It turns out that next to some of the patches in the issue tracker there's a
"review" link, wh
Dave Malcolm added the comment:
On Mon, 2012-02-06 at 23:00 +, Marc-Andre Lemburg wrote:
> Marc-Andre Lemburg added the comment:
>
> Alex Gaynor wrote:
> > There's no need to cover any container types, because if their constituent
> > types are securely hashable
Dave Malcolm added the comment:
> Can't randomization just be applied to integers as well?
>
It could, but see http://bugs.python.org/issue13703#msg151847
Would my patches be more or less likely to get reviewed with vs without
an extension of randomization
Dave Malcolm added the comment:
On Mon, 2012-02-06 at 10:20 +, Marc-Andre Lemburg wrote:
> Marc-Andre Lemburg added the comment:
>
> STINNER Victor wrote:
> >
> > STINNER Victor added the comment:
> >
> >> In a security fix release, we shouldn't
Dave Malcolm added the comment:
Am attaching a backport of
optin-hash-randomization-for-3.1-dmalcolm-2012-01-30-002.patch to 2.6
Randomization covers the str, unicode and buffer types; equality of hashes is
preserved for these types.
--
Added file:
http://bugs.python.org/file24375
1 - 100 of 417 matches
Mail list logo
