[issue11334] Failed to build _multiprocessing on Mac OS X
New submission from dave : hi community, i cannot import multiprocessing since it fails(?) during build. could someone point out a solution for me? thanks a lot in advance. dave $ python Python 2.7.1 (r271:86832, Feb 26 2011, 17:19:29) [GCC 4.2.1 (Apple Inc. build 5664)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import threading >>> import multiprocessing Traceback (most recent call last): File "", line 1, in File "/tools/python/lib/python2.7/multiprocessing/__init__.py", line 83, in import _multiprocessing ImportError: No module named _multiprocessing This is what i did to compile python 2.7: export MACOSX_DEPLOYMENT_TARGET=10.6 export ARCHFLAGS="-arch i386" export CXXFLAGS="-arch i386" export CFLAGS="-arch i386" export FFLAGS="-arch i386" export LDFLAGS="-Wall -undefined dynamic_lookup -arch i386" ./configure checking for --enable-universalsdk... no checking for --with-universal-archs... 32-bit checking MACHDEP... darwin checking EXTRAPLATDIR... $(PLATMACDIRS) checking machine type as reported by uname -m... i386 checking for --without-gcc... no checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for --with-cxx-main=... no checking for g++... g++ [...] config.status: pyconfig.h is unchanged creating Modules/Setup creating Modules/Setup.local creating Makefile make -j 4 [...] /private/var/tmp/Python-2.7.1/Modules/_multiprocessing/semaphore.c: In function 'semlock_acquire': /private/var/tmp/Python-2.7.1/Modules/_multiprocessing/semaphore.c:314: warning: implicit declaration of function 'sem_timedwait' *** WARNING: renaming "_multiprocessing" since importing it failed: dlopen(build/lib.macosx-10.6-i386-2.7/_multiprocessing.so, 2): Symbol not found: _sem_timedwait Referenced from: /private/var/tmp/Python-2.7.1/build/lib.macosx-10.6-i386-2.7/_multiprocessing.so Expected in: flat namespace in /private/var/tmp/Python-2.7.1/build/lib.macosx-10.6-i386-2.7/_multiprocessing.so [...] ranlib libpython2.7.a gcc -Wall -undefined dynamic_lookup -arch i386 -u _PyMac_Error -o python.exe \ Modules/python.o \ libpython2.7.a -ldl -framework CoreFoundation building dbm using ndbm Python build finished, but the necessary bits to build these modules were not found: _bsddb gdbm linuxaudiodev ossaudiodevsunaudiodev To find the necessary bits, look in setup.py in detect_modules() for the module's name. Failed to build these modules: _multiprocessing spwd -- assignee: ronaldoussoren components: Macintosh messages: 129573 nosy: dev66, ronaldoussoren priority: normal severity: normal status: open title: Failed to build _multiprocessing on Mac OS X type: compile error versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue11334> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11334] Failed to build _multiprocessing on Mac OS X
dave added the comment: seems the multiprocessing issue was produced by the dynamic_lookup parameter in the LDFLAGS... after removing this, "import multiprocessing" works... thanks > export LDFLAGS="-Wall -undefined dynamic_lookup -arch i386" -- resolution: -> works for me status: open -> closed ___ Python tracker <http://bugs.python.org/issue11334> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37546] colors in ttk treeview tags are ignored
New submission from dave :
The following example code fails in Python 3.7.3 64 bit (both lines are
displayed in black).
It works correctly in 3.7.2 and earlier.
import tkinter as tk
import tkinter.ttk as ttk
root = tk.Tk()
ttk.Label(root, text='This is a RED label', foreground='red').pack()
tree = ttk.Treeview(root)
tree.tag_configure('RED_TAG', foreground='red', font=('arial', 12))
tree.insert('', tk.END, text='Black line')
tree.insert('', tk.END, text='Red line', tag='RED_TAG')
tree.pack()
root.mainloop()
--
components: Tkinter
messages: 347618
nosy: dave9000
priority: normal
severity: normal
status: open
title: colors in ttk treeview tags are ignored
type: behavior
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue37546>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17139] dateTime.now() return format missing decimal seconds.
New submission from Dave:
Calling datetime.datetime.now() will return only the Date and time to the
second w/o the decimal portion when the second increments when also running
firefox w/shockwave flash enabled on a windows 7 machine.
Example output:
counter1 is: 23360 time is: 2013-02-05 16:32:24.999000
counter1 is: 23361 time is: 2013-02-05 16:32:25
counter1 is: 23362 time is: 2013-02-05 16:32:25.002000
Notice the missing decimal value on the middle one.
To reproduce:
Code:
counter = 0
while(True):
counter +=1
time = datetime.datetime.now()
numericDateTime =
print("counter1 is: " + str(counter) + " time is: " + time)
I can get this to occur every time that firefox is running with Shockwave flash
enabled.
datetime.now() works fine w/o firefox running w/shockwave flash enabled.
I believe the datetime.now() should always return the same format.
--
components: Windows
messages: 181484
nosy: Dave
priority: normal
severity: normal
status: open
title: dateTime.now() return format missing decimal seconds.
type: behavior
versions: Python 3.2
___
Python tracker
<http://bugs.python.org/issue17139>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17139] dateTime.now() return format missing decimal seconds.
Dave added the comment: Point was/is that I'd be willing to fix this so that others don't have to. It's for OTHERS SAKE that I submitted this issue as my system is already bullet proof from this defect/lack of feature situation. This is also my first attempt to get involved with the freeware community. Thanks, Dave -- ___ Python tracker <http://bugs.python.org/issue17139> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17139] dateTime.now() return format missing decimal seconds.
Dave added the comment: I appreciate you guys looking into this so quickly, but let's dig a little deeper. 1. STINNER Victor, you claim this is already fixed in 3.4 by the link, however this doesn't really help since I'm not even up to 3.3 yet (though I'm considering it, I meant to select 3.2 above). No one has yet provided any insight into why this condition only occurs when firefox is up running shockwave flash...(to me this is an even bigger question as I have a 7 other rather under tasked cores at my disposal). 2. Mark Dickinson, let's break this down. I've already worked around it as I’m sure that EVERYONE ELSE WHO USES IT has already done as well... We know as coders it's more difficult to work with a varying format (no advantage there). Which begs the question why not fix it so everyone doesn't have to? By the issue you referenced it's been known and unfixed since at least since 2004. Also, no curiosity why this only occurs when running firefox w/shockwave flash? Again I do appreciate you guys looking into this so quickly, but I don't know if this is actually going to get fixed, why it wasn't fixed in 2004, or is the Python motto "it's not broke if there exists a workaround". Odd that more time was spent talking about this (and Mark and myself independently implemented actual fixes) than the fix would have taken to apply to the baseline(I used to see this much other places I've worked). But I'm happy to say, I never saw responses back so quickly, which is very hopeful. Sincerely, Dave -- versions: +Python 3.2 -Python 3.4 ___ Python tracker <http://bugs.python.org/issue17139> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17139] dateTime.now() return format missing decimal seconds.
Dave added the comment: Thanks David Murry for clearing up STINNER Victor comments. I already feel like I work here;) So "it's not broke if there exists a workaround". In that case it's time to update the documents (which often takes longer than the code to update) to reflect this inconsistency so others won't run into this like I did (it took time to trouble shoot this as it was occurring prior to my logging being set up). It then took time to trap until I started web browsing:) State clearly in the API that the output format is either: "2013-02-05 16:32:24.999000" or "2013-02-05 16:32:25" depending on the time returned. I would also suggest deprecating the now(), __str__ and any method that exhibits this inconsistent multi-format output behavior since everyone after reading the updated comments will switch to another method immediately for simpler/more robust code. David Murry, said "Keep in mind that the str is a *convenience* representation. As such it is *much* more convenient to not print the zero microseconds in the very common case of constructed datetimes that have zero microseconds." Interesting since currently datetime does print the zeros microseconds in my example: "2013-02-05 16:32:24.999000" (notice the last 3 zeros are microseconds returned/printed by datetime.now()). Apparently this is inconvenient by your standards was well. I'm moving the status back to open for the documentation update and we'll see how anyone feels about the deprecation. All these little efforts have added up to something great "Python" and I hope these discussion will help further that cause. I appreciate everyone who has participated. Thanks, Dave -- resolution: rejected -> status: closed -> open type: enhancement -> behavior ___ Python tracker <http://bugs.python.org/issue17139> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17139] dateTime.now() return format missing decimal seconds.
Dave added the comment: Thanks for the reply, STINNER Victor reply makes more sense in hindsight. Legacy often rules and we can work with/around things knowing it's full behavior. Since this is not documented for datetime.now()(where this issue began), can we add comments something like what was done for __str__, so the two possible output formats are documented? Thanks, Dave -- resolution: invalid -> status: closed -> open ___ Python tracker <http://bugs.python.org/issue17139> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17139] dateTime.now() return format missing decimal seconds.
Dave added the comment: Ok, as a c++ guy, it looked like it's returning a string. The documentation says "Return the current local date and time", but it's actually returning a datetime object (likely an object pointer) initialized to the current time. I think this is where every class inherits from a common base class which must include the __str__ method or something to that effect. Then printing the ptr/ref to the datetime.now() object actually just call's it's __str__ method. I get this now. I need to study the Python inner workings to get a better sense of this, but this has helped much (my current books are more functional, but too primitive). Thanks again David Murray for taking the time to fully address this issue and to everyone who participated. Issue closed, action to me to learn more python. If anyone knows a good deeper book on it, please pass on the title. Sincerely, Dave -- ___ Python tracker <http://bugs.python.org/issue17139> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17139] dateTime.now() return format missing decimal seconds.
Dave added the comment: I'll order it. Thanks again, Dave -- ___ Python tracker <http://bugs.python.org/issue17139> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1222] locale.format bug if thousand separator is space (french separator as example)
Changes by Dave Hughes: -- nosy: +waveform __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1222> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9216] FIPS support for hashlib
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/file23172/0001-Rework-_hashlib-caching-moving-per-hash-cached-data-.patch ___ Python tracker <http://bugs.python.org/issue9216> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9216] FIPS support for hashlib
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/issue9216> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9216] FIPS support for hashlib
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/issue9216> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9216] FIPS support for hashlib
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/issue9216> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9216] FIPS support for hashlib
Dave Malcolm added the comment: [and yes, I used git to generate the 4 patches; sorry ] -- ___ Python tracker <http://bugs.python.org/issue9216> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9216] FIPS support for hashlib
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 to only use _hashlib, rather than falling back on _md5 etc, since otherwise you get confusing error messages from hashlib.md5() when it defers to _md5 due to FIPS enforcement. In my downstream builds we can be sure of building against OpenSSL, but this other part of the patch seems less appropriate for upstream python, given that upstream python tries to be flexible in terms of its dependencies. Hope this makes sense. -- ___ Python tracker <http://bugs.python.org/issue9216> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12913] Add a debugging howto
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 mentioned). > If the devguide is updated, I will be content with just one line containing > one link in my howto. Currently we have this wiki page: > http://wiki.python.org/moin/DebuggingWithGdb I also remember a ubuntu wiki > page with more useful info but can’t find the bookmark. > > > FTR, I will use these resources: > https://pythonconquerstheuniverse.wordpress.com/2009/09/10/debugging-in-python/ > and http://www.jeetworks.org/node/99 There's also: http://docs.python.org/devguide/gdb.html -- nosy: +dmalcolm ___ Python tracker <http://bugs.python.org/issue12913> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13315] Unable to deal with large tarfile
New submission from Dave Flogeras : I am trying to unpack boost_1_46_1.tar.bz2 (you can grab it here http://mirror.its.dal.ca/gentoo/distfiles/boost_1_46_1.tar.bz2) with the following code: import tarfile t = tarfile.open( "boost_1_46_1.tar.bz2" ); t.extractall() On OSX (both Lion and Snow Leopard, so python 2.7.1 and 2.6.1 resp.) this works as a normal user, but not as root failing with: Traceback (most recent call last): File "", line 1, in File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/tarfile.py", line 2028, in extractall self.extract(tarinfo, path) File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/tarfile.py", line 2065, in extract self._extract_member(tarinfo, os.path.join(path, tarinfo.name)) File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/tarfile.py", line 2157, in _extract_member self.chown(tarinfo, targetpath) File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/tarfile.py", line 2269, in chown os.chown(targetpath, u, g) OverflowError: signed integer is greater than maximum I have confirmed that Python is running as a 64bit application on OSX. On my 64bit Linux (gentoo) machine, this works both as a user and as root. I tried with Python 2.7.2 as well as downgrading to 2.7.1. This could be related to 1215928 -- messages: 146800 nosy: Dave.Flogeras priority: normal severity: normal status: open title: Unable to deal with large tarfile versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue13315> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13315] tarfile extract fails on OS X system python due to chown of gid=-1
Dave Flogeras added the comment: Thank you sirs. I've already got a workaround for this situation, and personally don't care to waste my time with apple. I'm satisfied that Python is handling bugs seriously and it will hopefully get into an apple release in the future. -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue13315> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13391] string.strip Does Not Remove Zero-Width-Space (ZWSP)
New submission from Dave Mankoff :
Title pretty much says it all. Simple test case:
>>> len(u' \t\r\n\u200B'.strip())
1
Should be zero.
Same problem in Python3:
>>> len(' \t\r\n\u200B'.strip())
1
--
components: Unicode
messages: 147538
nosy: ezio.melotti, mankyd
priority: normal
severity: normal
status: open
title: string.strip Does Not Remove Zero-Width-Space (ZWSP)
type: behavior
versions: Python 2.7, Python 3.2
___
Python tracker
<http://bugs.python.org/issue13391>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13391] string.strip Does Not Remove Zero-Width-Space (ZWSP)
Dave Mankoff added the comment: I appreciated the quick turnaround on this. Perhaps I am misunderstanding the resolution. I understand that strip uses _PyUnicode_IsWhitespace, and that _PyUnicode_IsWhitespace "Returns 1 for Unicode characters having the bidirectional type 'WS', 'B' or 'S' or the category 'Zs', 0 otherwise." However, perhaps this is where the functionality is missing? Upon further inspection, it looks like there may be other missing white-space characters, such as U+FEFF, "Zero Width No-Break Space". Whatever unicode categories their in, they're still a form of white-space and should still be removed, no? This was not the behavior I expected from strip(). This affects string.issspace() as well. I now have to put var.strip().strip(u'\u200B\ufeff') anywhere I want to test for whitespace strings in all my future python code. (I was bit by exactly this issue in my code which is what caused me to file the issue in the first place.) -- ___ Python tracker <http://bugs.python.org/issue13391> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13391] string.strip Does Not Remove Zero-Width-Space (ZWSP)
Dave Mankoff added the comment: But why are they not a space? I mean, they literally have the word space in their name and are used as separators between words. I can't really see any reason why you wouldn't want this behavior - there's not time when I would be thankful that strip removed all spaces except for ZWSP and the likes. As to deprecation, yes, that is true, but they still exist and will continue to do so. (My issue arose when a 3rd party delivered an all whitespace string to me.) I can't really debate this further as there's not much more to say. I hope the issue will be reconsidered. Thanks again for taking the time to discuss. -- ___ Python tracker <http://bugs.python.org/issue13391> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13391] string.strip Does Not Remove Zero-Width-Space (ZWSP)
Dave Mankoff added the comment: So I contacted the Unicode Technical Committee about the issue and received a promptly received a response back. They pointed that the ZWSP was, once upon a time considered white space but that was changed in Unicode 4.0.1 http://www.unicode.org/review/resolved-pri.html#pri21 One particular comment worth noting: "... for historical reasons the general category is still Zs (Space Separator)". Perhaps this ticket can be changed to a feature request? In addition to stripping out whitespace, it is useful to remove any non-printable characters from a string (or know if a string contains any non-printable characters). Perhaps a boolean keyword parameter, "control_chars" could be added to isspace and strip? Thus: >>> u' \t\r\n\u200B'.isspace(control_chars=True) True -- ___ Python tracker <http://bugs.python.org/issue13391> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13391] string.strip Does Not Remove Zero-Width-Space (ZWSP)
Dave Mankoff added the comment: "Use regular expressions for more advanced stripping than what the .strip method provides." So I guess this brings me back to my original issue. I'm not looking for particularly advanced stripping. I just want to remove all whitespace and other non-printing characters. I personally can never think of a time when I wouldn't want this (especially with isspace). Maybe in some applications, the control characters are useful and shouldn't be stripped, but I would argue that _that_ is the more advanced use case for most people. Thus strip and isspace are now unusable methods in Python for common use cases. This seems unfortunate. I can understand the claims of feature creep. I even understand that having isspace compare itself against non-whitespace characters may seem counter-intuitive on its face. But certainly there must be a satisfactory remedy here. -- ___ Python tracker <http://bugs.python.org/issue13391> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13390] Hunt memory allocations in addition to reference leaks
Changes by Dave Malcolm : -- nosy: +dmalcolm ___ Python tracker <http://bugs.python.org/issue13390> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13534] test_cmath fails on ppc with glibc-2.14.90 due to optimized architecture-specific "hypot"
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)
--
Traceback (most recent call last):
File "/builddir/build/BUILD/Python-2.7.2/Lib/test/test_cmath.py", line 352,
in test_specific_values
msg=error_message)
File "/builddir/build/BUILD/Python-2.7.2/Lib/test/test_cmath.py", line 112,
in rAssertAlmostEqual
'{!r} and {!r} are not sufficiently close'.format(a, b))
AssertionError: acos0200: acos(complex(1.620686051868302e+308,
1.0308426226285283e+308))
Expected: complex(0.5665082609382622, -710.5420687424156)
Received: complex(0.5665082609382622, -inf)
Received value insufficiently close to expected value.
It turns out (after much debugging) that libm in this version of glibc has an
architecture-specific implementation of hypot(3) which returns inf in many of
the test cases in tests/cmath_testcases.txt, when the non-architecture-specific
implementation returns large finite values.
See downstream bug in Fedora's bug tracker:
https://bugzilla.redhat.com/show_bug.cgi?id=750811
for more details.
Seen with the Python 2.7.2 tarball, but the code doesn't appear to have changed
in hg in either the default or the 2.7 branches.
I will also file a bug in glibc's bug tracker about this.
--
components: Tests
messages: 148893
nosy: dmalcolm
priority: normal
severity: normal
status: open
title: test_cmath fails on ppc with glibc-2.14.90 due to optimized
architecture-specific "hypot"
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
___
Python tracker
<http://bugs.python.org/issue13534>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13534] test_cmath fails on ppc with glibc-2.14.90 due to optimized architecture-specific "hypot"
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/issue13534> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13534] test_cmath fails on ppc with glibc-2.14.90 due to buggy architecture-specific "hypot"
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" -> test_cmath fails on ppc with glibc-2.14.90 due to buggy architecture-specific "hypot" ___ Python tracker <http://bugs.python.org/issue13534> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13534] test_cmath fails on ppc with glibc-2.14.90 due to buggy 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 ___ Python tracker <http://bugs.python.org/issue13534> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Changes by Dave Malcolm : -- nosy: +dmalcolm ___ Python tracker <http://bugs.python.org/issue13703> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12055] doctest not working on nested functions
Dave Abrahams added the comment: It's certainly much appreciated, but my tests have to run with a stock python, so I worked around the problem personally. I just reported this because I found (surprisingly, to me) that some of my tests had been silently not-running, which seems like a bad feature of any testing system ;=). On Mon, May 23, 2011 at 12:15 PM, Baptiste Carvello wrote: > > Baptiste Carvello added the comment: > > here is the patch for 2.7. > > Dave: I don't know if or when the patch will be accepted, as this is a new > feature. In the meantime, you can easily patch your system. As the code > changes > are all in Python, you don't need to recompile. Going to your standard library > directory and running a command like the following should do the trick: > > filterdiff -i '*/doctest.py' issue12055-27.diff | patch > > -- > Added file: http://bugs.python.org/file22085/issue12055-27.diff > > ___ > Python tracker > <http://bugs.python.org/issue12055> > ___ -- ___ Python tracker <http://bugs.python.org/issue12055> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2466] os.path.ismount doesn't work for mounts the user doesn't have permission to see
Dave Rawks added the comment: Confirm this problem exists in 2.7 as well. -- nosy: +drawks versions: +Python 2.7 ___ Python tracker <http://bugs.python.org/issue2466> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8927] Handle version incompatibilities in dependencies
Dave Abrahams added the comment: I'm sorry, but it is simply not true that this is not a solved problem. This is a well-understood problem that's solved --- at least as well as anyone could want it to be --- by aptitude (not apt-get) and by http://en.opensuse.org/openSUSE:Libzypp_satsolver -- ___ Python tracker <http://bugs.python.org/issue8927> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8927] Handle version incompatibilities in dependencies
Dave Abrahams added the comment: That's quite true. However, I don't think a local index is needed if there's a remote index; you're already looking in a remote index, albeit a less-completeone. And it could be maintained automatically from individual package metadata. Maybe that's out of scope for this project, though. -- ___ Python tracker <http://bugs.python.org/issue8927> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10527] multiprocessing.Pipe problem: "handle out of range in select()"
Changes by Dave Malcolm : -- nosy: +dmalcolm ___ Python tracker <http://bugs.python.org/issue10527> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10527] multiprocessing.Pipe problem: "handle out of range in select()"
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 should do the same. -- ___ Python tracker <http://bugs.python.org/issue10527> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10527] multiprocessing.Pipe problem: "handle out of range in select()"
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.org/issue10527> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10527] multiprocessing.Pipe problem: "handle out of range in select()"
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/issue10527> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11376] Solaris/GCC/shared lib problem
Dave Abrahams added the comment: I run: sudo pip install --upgrade twisted -- ___ Python tracker <http://bugs.python.org/issue11376> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11376] Solaris/GCC/shared lib problem
Dave Abrahams added the comment: Note: even after I install Sun CC, -KPIC is unrecognized. At least it's only a warning in this case: $ sudo pip install --upgrade twisted Downloading/unpacking twisted Running setup.py egg_info for package twisted Downloading/unpacking zope.interface (from twisted) Running setup.py egg_info for package zope.interface Downloading/unpacking setuptools (from zope.interface->twisted) Running setup.py egg_info for package setuptools Installing collected packages: setuptools, twisted, zope.interface Found existing installation: setuptools 0.6c12dev-r88846 Uninstalling setuptools: Successfully uninstalled setuptools Running setup.py install for setuptools Installing easy_install script to /usr/bin Installing easy_install-2.6 script to /usr/bin Found existing installation: Twisted 10.0.0 Uninstalling Twisted: Successfully uninstalled Twisted Running setup.py install for twisted /usr/lib/python2.6/pycc -DNDEBUG -KPIC -I/usr/include/python2.6 -c conftest.c -o conftest.o cc: unrecognized option `-KPIC' /usr/lib/python2.6/pycc -DNDEBUG -KPIC -I/usr/include/python2.6 -c conftest.c -o conftest.o cc: unrecognized option `-KPIC' conftest.c:1:23: sys/epoll.h: No such file or directory building 'twisted.runner.portmap' extension /usr/lib/python2.6/pycc -DNDEBUG -KPIC -I/usr/include/python2.6 -c twisted/runner/portmap.c -o build/temp.solaris-2.11-i86pc-2.6/twisted/runner/portmap.o cc: unrecognized option `-KPIC' /usr/lib/python2.6/pycc -G build/temp.solaris-2.11-i86pc-2.6/twisted/runner/portmap.o -L/usr/lib -lpython2.6 -o build/lib.solaris-2.11-i86pc-2.6/twisted/runner/portmap.so building 'twisted.test.raiser' extension /usr/lib/python2.6/pycc -DNDEBUG -KPIC -I/usr/include/python2.6 -c twisted/test/raiser.c -o build/temp.solaris-2.11-i86pc-2.6/twisted/test/raiser.o cc: unrecognized option `-KPIC' /usr/lib/python2.6/pycc -G build/temp.solaris-2.11-i86pc-2.6/twisted/test/raiser.o -L/usr/lib -lpython2.6 -o build/lib.solaris-2.11-i86pc-2.6/twisted/test/raiser.so building 'twisted.python._initgroups' extension /usr/lib/python2.6/pycc -DNDEBUG -KPIC -I/usr/include/python2.6 -c twisted/python/_initgroups.c -o build/temp.solaris-2.11-i86pc-2.6/twisted/python/_initgroups.o cc: unrecognized option `-KPIC' /usr/lib/python2.6/pycc -G build/temp.solaris-2.11-i86pc-2.6/twisted/python/_initgroups.o -L/usr/lib -lpython2.6 -o build/lib.solaris-2.11-i86pc-2.6/twisted/python/_initgroups.so building 'twisted.internet._sigchld' extension /usr/lib/python2.6/pycc -DNDEBUG -KPIC -I/usr/include/python2.6 -c twisted/internet/_sigchld.c -o build/temp.solaris-2.11-i86pc-2.6/twisted/internet/_sigchld.o cc: unrecognized option `-KPIC' In file included from /usr/include/python2.6/Python.h:8, from twisted/internet/_sigchld.c:9: /usr/include/python2.6/pyconfig.h:1004:1: warning: "_FILE_OFFSET_BITS" redefined In file included from /usr/include/signal.h:36, from twisted/internet/_sigchld.c:6: /usr/include/sys/feature_tests.h:209:1: warning: this is the location of the previous definition /usr/lib/python2.6/pycc -G build/temp.solaris-2.11-i86pc-2.6/twisted/internet/_sigchld.o -L/usr/lib -lpython2.6 -o build/lib.solaris-2.11-i86pc-2.6/twisted/internet/_sigchld.so changing mode of build/scripts-2.6/manhole from 644 to 755 changing mode of build/scripts-2.6/mktap from 644 to 755 changing mode of build/scripts-2.6/pyhtmlizer from 644 to 755 changing mode of build/scripts-2.6/twistd from 644 to 755 changing mode of build/scripts-2.6/trial from 644 to 755 changing mode of build/scripts-2.6/tap2rpm from 644 to 755 changing mode of build/scripts-2.6/tap2deb from 644 to 755 changing mode of build/scripts-2.6/tapconvert from 644 to 755 changing mode of build/scripts-2.6/mailmail from 644 to 755 changing mode of build/scripts-2.6/conch from 644 to 755 changing mode of build/scripts-2.6/cftp from 644 to 755 changing mode of build/scripts-2.6/tkconch from 644 to 755 changing mode of build/scripts-2.6/ckeygen from 644 to 755 changing mode of build/scripts-2.6/lore from 644 to 755 changing mode of /usr/bin/tap2deb to 755 changing mode of /usr/bin/ckeygen to 755 changing mode of /usr/bin/tap2rpm to 755 changing mode of /usr/bin/mktap to 755 changing mode of /usr/bin/pyhtmlizer to 755 changing mode of /usr/bin/twistd to 755 changing mode of /usr/bin/lore to 755 changing mode of /usr/bin/mailmail to 755 changing mode of /usr/bin/cftp to 755 changing mode of /usr/bin/tkconch to 755 changing mode of /usr/bin/conch to 755 changing mode of /usr/bin/trial to 755 changing mode of /usr/bin/tapconvert to 755 changing mode of /usr/bin/manhole to
[issue975330] Inconsistent newline handling in email module
Dave King added the comment: Added some tests against the patch provided by R. David Murray. See attached patch. Tests pass against default. -- nosy: +davbo Added file: http://bugs.python.org/file22473/base_encode_tests.patch ___ Python tracker <http://bugs.python.org/issue975330> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8890] Use tempfile instead of /tmp in examples
Dave King added the comment: Spotted another use of /tmp/ in the logging howto. Attached a diff. -- nosy: +davbo Added file: http://bugs.python.org/file22483/tmp_logging_howto.diff ___ Python tracker <http://bugs.python.org/issue8890> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12509] test_gdb fails on debug build when builddir != srcdir
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 regexp, and I don't think it's affected by an analogous problem. -- assignee: dmalcolm components: None files: fix-test_gdb-regexp.patch keywords: patch messages: 139960 nosy: dmalcolm, haypo priority: normal severity: normal stage: patch review status: open title: test_gdb fails on debug build when builddir != srcdir versions: Python 3.1, Python 3.2 Added file: http://bugs.python.org/file22600/fix-test_gdb-regexp.patch ___ Python tracker <http://bugs.python.org/issue12509> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11254] distutils doesn't byte-compile .py files to __pycache__ during installation
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 various python3-* rpm packages (as generated by distutils). rpm's post-processing has been generating .pyc files in the (correct) __pycache__ location (via rpmbuild's brp-python-bytecompile script, which uses "compileall"). For examples, see that Fedora bug report; so far it's affected every built rpm I've looked at. I believe the impact of the extra .pyc files is merely wasted disk space within our rpm-packaged Python 3.2 stack. I'm thinking of applying the patch to our downstream python3.src.rpm -- nosy: +dmalcolm ___ Python tracker <http://bugs.python.org/issue11254> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12605] Enhancements to gdb 7 debugging hooks
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 patch changes this, dividing C frames into: - "python frames": - "bytecode frames" i.e. PyEval_EvalFrameEx - "other python frames": C frames that are of interest from a python perspective, but aren't bytecode - everything else so that the "py-bt", "py-up" and "py-down" commands will now work on the other kinds of "python" frames, in addition to the bytecode frames. Specifically, the following new kinds of C frame are displayed: - waiting on the GIL - garbage-collection - CFunctions (these weren't displayed before) This should assist when debugging multithreaded crashes, to more easily get a sense of what every thread is doing. Examples: Showing a garbage-collection: (gdb) py-bt Garbage-collecting File "", line 4, in foo File "", line 6, in bar File "", line 7, in (gdb) py-bt-full #1 Garbage-collecting #2 #5 Frame 0x720d6d48, for file , line 4, in foo () #8 Frame 0x720d6b70, for file , line 6, in bar () #11 Frame 0x77fb1d80, for file , line 7, in () Showing an invocation of "time.sleep()": (gdb) py-bt-full #0 #3 Frame 0x718aa060, for file , line 3, in foo () #6 Frame 0x720d6b70, for file , line 5, in bar () #9 Frame 0x77fb1d80, for file , line 6, in () Showing multiple threads, where all but one are waiting for the GIL: Thread 5 (Thread 0x7fffeb5fe700 (LWP 10716)): Traceback (most recent call first): Waiting for the GIL File "", line 10, in run File "/home/david/coding/python-hg/cpython-more-gdb/build-debug/../Lib/threading.py", line 737, in _bootstrap_inner self.run() File "/home/david/coding/python-hg/cpython-more-gdb/build-debug/../Lib/threading.py", line 710, in _bootstrap self._bootstrap_inner() Thread 4 (Thread 0x7fffebfff700 (LWP 10715)): Traceback (most recent call first): Waiting for the GIL File "", line 10, in run File "/home/david/coding/python-hg/cpython-more-gdb/build-debug/../Lib/threading.py", line 737, in _bootstrap_inner self.run() File "/home/david/coding/python-hg/cpython-more-gdb/build-debug/../Lib/threading.py", line 710, in _bootstrap self._bootstrap_inner() Thread 3 (Thread 0x70dea700 (LWP 10714)): Traceback (most recent call first): Waiting for the GIL File "", line 10, in run File "/home/david/coding/python-hg/cpython-more-gdb/build-debug/../Lib/threading.py", line 737, in _bootstrap_inner self.run() File "/home/david/coding/python-hg/cpython-more-gdb/build-debug/../Lib/threading.py", line 710, in _bootstrap self._bootstrap_inner() Thread 2 (Thread 0x717eb700 (LWP 10713)): Traceback (most recent call first): Waiting for the GIL File "", line 10, in run File "/home/david/coding/python-hg/cpython-more-gdb/build-debug/../Lib/threading.py", line 737, in _bootstrap_inner self.run() File "/home/david/coding/python-hg/cpython-more-gdb/build-debug/../Lib/threading.py", line 710, in _bootstrap self._bootstrap_inner() Thread 1 (Thread 0x77fdb700 (LWP 10709)): Traceback (most recent call first): File "", line 18, in -- assignee: dmalcolm components: Demos and Tools keywords: needs review messages: 140828 nosy: dmalcolm, haypo priority: normal severity: normal status: open title: Enhancements to gdb 7 debugging hooks versions: Python 2.7, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue12605> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12605] Enhancements to gdb 7 debugging hooks
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/issue12605> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12605] Enhancements to gdb 7 debugging hooks
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-hooks-2.7.patch ___ Python tracker <http://bugs.python.org/issue12605> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
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 kernel-3.0 with python-2.7.2-4.fc16.x86_64 and python is reporting: $ python -c"import sys; print(sys.platform)" linux2 I investigated why we have this discrepancy: "uname" with the build environment for that RPM happens to be reporting a kernel-2*, whereas we're shipping a kernel-3*: http://koji.fedoraproject.org/koji/taskinfo?taskID=3187563 What's happening here is that although the chroot that the build was done in [1] has: kernel-3.0-0.rc6.git0.1.fc16.x86_64.rpm running "uname" in the chroot environment is reporting the kernel that's actually running, outside the chroot, which was: 2.6.32 and thus we have: checking MACHDEP... linux2 within the build log [2] So in this case, "sys.platform"'s final digit is reporting the major release of the kernel running outside the chroot-ed build environment (ironically bearing even less relationship to that of the currently-running kernel :( ) Hope this is helpful [1] http://koji.fedoraproject.org/koji/rpmlist?buildrootID=1096117%20&start=50&order=nvr&type=component [2] http://kojipkgs.fedoraproject.org/packages/python/2.7.2/4.fc16/data/logs/x86_64/build.log -- nosy: +dmalcolm ___ Python tracker <http://bugs.python.org/issue12326> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
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 final digit of sys.platform (thankfully this is now recommended by: http://docs.python.org/library/sys.html#sys.platform ) - unfortunately there is code out there that checks against "linux2" and thus does rely on this value - patching CPython to force this to read "linux2" may be necessary for some downstream distributors of Python, to maximize compatibility with such broken code. For CPython, "sys.platform" currently reports on the difference between whether "uname" reported linux2 or linux3 at build time, which is currently meaningless (see msg142219 above about our chroot-ed build environment). For example, in RHEL we may at some future time upgrade our build farm to linux 3, but still provision our build trees within it for linux 2; this may mean that our build farm starts reporting "linux3" when rebuilding security updates for python 2.2, 2.3, 2.4 or 2.6, even when building against kernel-2.*'s user-space. If this happens, I'd be inclined to patch those builds of Python back to "linux2". It would be entirely meaningless and only damaging for one of our security updates of, say, Python 2.2 to shift sys.platform from "linux2" to "linux3" simply because of the kernel that was running in the build environment (as opposed to the kernel headers exposed to the compiler, and other such aspects of the kernel exposed in user-space). FWIW, my opinion is currently: - in 3.3, sys.platform on linux should be simply "linux" - for 2.7 and 3.2, sys.platform should be forced to "linux2" (and indeed, I anticipate doing this for earlier releases that I still maintain downstream) - existing documentation should say that on linux, sys.platform begins with "linux", and that programmers should avoid relying upon the suffix - I don't see the need for more adding access to more details of the build platform (and I can poke holes in any such plan, if anyone wants me to: what would it contain? what about the case where the user-space files e.g. headers aren't the same as the uname? etc) -- ___ Python tracker <http://bugs.python.org/issue12326> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12872] --with-tsc crashes on ppc64
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 support.
35 "__ppc__" appears to be the preprocessor definition to detect on OS
X, whereas
36 "__powerpc__" appears to be the correct one for Linux with GCC
37 */
38 #if defined(__ppc__) || defined (__powerpc__)
39
40 #define READ_TIMESTAMP(var) ppc_getcounter(&var)
41
42 static void
43 ppc_getcounter(uint64 *v)
44 {
45 register unsigned long tbu, tb, tbu2;
46
47loop:
48 asm volatile ("mftbu %0" : "=r" (tbu) );
49 asm volatile ("mftb %0" : "=r" (tb) );
50 asm volatile ("mftbu %0" : "=r" (tbu2));
51 if (__builtin_expect(tbu != tbu2, 0)) goto loop;
52
53 /* The slightly peculiar way of writing the next lines is
54 compiled better by GCC than any other way I tried. */
55 ((long*)(v))[0] = tbu;
56 /*((long*)(v))[1] = tb; */ /* < this is the bug */
57 }
58
59 #elif defined(__i386__)
(gdb) p sizeof(long)
$44 = 8
(gdb) p sizeof(uint64)
$45 = 8
Looks like lines 55 and 56 are erroneously assuming that a long is 4 bytes on
this arch: line 56 above is trashing the next value beyond the timer value,
which is on the machine's stack, corrupting local variables within
PyEval_EvalFrameEx.
The code has been this way since ppc_getcounter was added, in:
http://hg.python.org/cpython/rev/f455bbe7ea7e
I may have broken this in:
http://hg.python.org/cpython/rev/419ca089d365/
which was for:
http://bugs.python.org/issue10655
by (perhaps) generalizing support from ppc to (ppc and ppc64) (not sure about
this).
I'm attaching a patch which splits the ppc tsc support into 32-bit and 64-bit
parts, and which also removes an aliasing violation on 32-bit ppc.
(I'm tracking this downstream in Fedora's bug tracker as
https://bugzilla.redhat.com/show_bug.cgi?id=698726 )
--
components: Interpreter Core
files: python-2.7.2-tsc-on-ppc.patch
keywords: patch
messages: 143281
nosy: dmalcolm
priority: normal
severity: normal
stage: patch review
status: open
title: --with-tsc crashes on ppc64
type: crash
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file23079/python-2.7.2-tsc-on-ppc.patch
___
Python tracker
<http://bugs.python.org/issue12872>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9623] test_site.py has a couple of stray self.assertTrue calls that test for equality
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, but a couple remain (introduced in r74526) in both 2.7 branch and py3k. Patch attached (for 2.7 branch) -- components: Tests keywords: easy, needs review, patch messages: 114069 nosy: dmalcolm priority: normal severity: normal stage: patch review status: open title: test_site.py has a couple of stray self.assertTrue calls that test for equality type: behavior versions: Python 2.7, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue9623> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9623] test_site.py has a couple of stray self.assertTrue calls that test for equality
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/file18549/fix-stray-assertTrue-calls.patch ___ Python tracker <http://bugs.python.org/issue9623> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9628] runtests.sh -x doesn't work with more than two args (sed error)
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 runtests.sh need to add the trailing "g" flag to substitute all matches. >From "info sed": The `s' command can be followed by zero or more of the following FLAGS: `g' Apply the replacement to _all_ matches to the REGEXP, not just the first. Am attaching a patch. (Seen with sed-4.2.1 on Fedora 13) -- components: Tests files: fix-sed-invocations-in-runtests.sh.patch keywords: easy, needs review, patch, patch messages: 114134 nosy: dmalcolm priority: normal severity: normal stage: patch review status: open title: runtests.sh -x doesn't work with more than two args (sed error) versions: Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file18554/fix-sed-invocations-in-runtests.sh.patch ___ Python tracker <http://bugs.python.org/issue9628> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9628] runtests.sh -x doesn't work with more than two args (sed error)
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 tracker <http://bugs.python.org/issue9628> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9629] SIZEOF_SOCKET_T used in longobject.h but undefined
Dave Malcolm added the comment: Looks like a dup of issue 4835 -- nosy: +dmalcolm ___ Python tracker <http://bugs.python.org/issue9629> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9629] SIZEOF_SOCKET_T used in longobject.h but undefined
Changes by Dave Malcolm : -- resolution: -> duplicate status: open -> closed superseder: -> SIZEOF_SOCKET_T not defined ___ Python tracker <http://bugs.python.org/issue9629> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue515074] Extended storage in new-style classes
Dave Abrahams added the comment: I can't imagine what kind of "positive response" you'd want from me. I responded to the last question asked. I certainly don't know whether this is still an issue, though. -- nosy: +dabrahams status: pending -> open ___ Python tracker <http://bugs.python.org/issue515074> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9631] Python 2.7 installation issue for Linux gcc-4.1.0-3 (Fedora Core 5?)
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 the bug accordingly) -- nosy: +dmalcolm title: Python 2.7 installation issue for Linux Red Hat 4.1 -> Python 2.7 installation issue for Linux gcc-4.1.0-3 (Fedora Core 5?) ___ Python tracker <http://bugs.python.org/issue9631> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9635] RFE(patch): add Py_BREAKPOINT and sys.breakpoint hooks
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
complexity of evaluating the conditional in the debugger process, or deficiency
of the debugger itself).
I'm attaching a patch which:
- adds a Py_BREAKPOINT macro to pyport.h This is available as a quick and
dirty way of hardcoding a breakpoint in code (e.g. in extension modules); so
that when you need to you can put of these in (perhaps guarded by C-level
conditionals):
if (complex_conditional()) {
Py_BREAKPOINT();
}
- when Py_BREAKPOINT is defined, adds a sys.breakpoint() method. This means
that you can add C-level breakpoints to Python scripts, perhaps guarded by
python-level conditionals:
if foo and bar and not baz:
sys.breakpoint()
Naturally this is highly system-dependent. Only tested on Linux (Fedora 13
x86_64 with gcc-4.4.4). The Windows implementation was copied from
http://bugs.python.org/issue8863 but I don't have a Windows box to test it on.
I note that the GLib library within GNOME has a similar idea with a
G_BREAKPOINT macro, which has accumulated a collection of platform-specific
logic:
http://git.gnome.org/browse/glib/tree/glib/gbacktrace.h
(unfortunately that's LGPLv2+ licensed)
Doesn't yet have a unit test.
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.
--
components: Interpreter Core, Library (Lib)
files: add-sys.breakpoint.patch
keywords: patch, patch
messages: 114301
nosy: dmalcolm, haypo
priority: normal
severity: normal
stage: patch review
status: open
title: RFE(patch): add Py_BREAKPOINT and sys.breakpoint hooks
type: feature request
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file18572/add-sys.breakpoint.patch
___
Python tracker
<http://bugs.python.org/issue9635>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9635] RFE(patch): add Py_BREAKPOINT and sys.breakpoint hooks
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. Looks like Windows' DebugBreak has similar behavior here; according to: http://msdn.microsoft.com/en-us/library/ms679297(VS.85).aspx "If the process is not being debugged, the function uses the search logic of a standard exception handler. In most cases, this causes the calling process to terminate because of an unhandled breakpoint exception." -- ___ Python tracker <http://bugs.python.org/issue9635> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9687] dbmmodule.c:dbm_contains fails on 64bit big-endian (test_dbm.py fails) when built against gdbm (int vs Py_ssize_t)
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 of RHEL6, with
gdbm-devel-1.8.0-36.el6.ppc64)
All of the headers define datum as:
typedef struct {
char *dptr;
int dsize;
} datum;
Note the use of "int" for dsize.
This fragment of code in python's Modules/dbmmodule.c:dbm_contains:
if (PyString_AsStringAndSize(v, (char **)&key.dptr,
(Py_ssize_t *)&key.dsize)) {
return -1;
}
appears to assume that
sizeof(datum.dsize) == sizeof(Py_ssize_t)
which is not correct on these architectures:
(gdb) p sizeof(key.dsize)
$25 = 4
(gdb) p sizeof(Py_ssize_t)
$26 = 8
On ppc64, when PyString_AsStringAndSize writes the 0x1 value
for the ob_size of "a" to &key.dsize, I believe the 0x part is written
to &key.size, and the 0x0001 part is written to the 4 bytes following it,
due to the incorrect cast from (int*) to (Py_ssize_t*)
Thankfully
(gdb) p sizeof(key)
$28 = 16
so it writes this value to padding within the "datum key", rather than
corrupting the stack.
The dbm_fetch() invocation is thus passed a 0 dsize, and doesn't find the key,
hence the test fails.
The various other uses with that source file appear correct:
(i) there are various PyArg_Parse* calls using s#, with int, which is correct,
given the absence of the PY_SSIZE_T_CLEAN macro.
(ii) there are various calls of PyString_FromStringAndSize(, datum.dsize),
which I believe is correct: I believe the compiler will coerce this int to the
wider Py_ssize_t type.
I'm attaching a patch which (I hope) correctly coerces the size of the key from
Py_ssize_t to "int" within gdb_contains.
--
components: Extension Modules
files: fix-dbm_contains-on-64bit-bigendian.patch
keywords: patch, patch
messages: 114934
nosy: dmalcolm
priority: normal
severity: normal
stage: patch review
status: open
title: dbmmodule.c:dbm_contains fails on 64bit big-endian (test_dbm.py fails)
when built against gdbm (int vs Py_ssize_t)
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2
Added file:
http://bugs.python.org/file18644/fix-dbm_contains-on-64bit-bigendian.patch
___
Python tracker
<http://bugs.python.org/issue9687>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9687] dbmmodule.c:dbm_contains fails on 64bit big-endian (test_dbm.py fails) when built against gdbm (int vs Py_ssize_t)
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.org/issue9687> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9688] object.__basicsize__ is erroneously0
Changes by Dave Malcolm : -- nosy: dmalcolm priority: normal severity: normal status: open title: object.__basicsize__ is erroneously0 ___ Python tracker <http://bugs.python.org/issue9688> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9688] object.__basicsize__ is erroneously 0 on big-endian 64-bit machines (int vs Py_ssize_t)
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
instead; see https://bugzilla.redhat.com/show_bug.cgi?id=627347 )
struct _typeobject declares tp_basicsize and tp_itemsize as Py_ssize_t:
{
...
Py_ssize_t tp_basicsize, tp_itemsize; /* For allocation */
...
}
but type_members defines them as T_INT:
{"__basicsize__", T_INT, offsetof(PyTypeObject,tp_basicsize),READONLY},
{"__itemsize__", T_INT, offsetof(PyTypeObject, tp_itemsize), READONLY},
Hence when accessing "object.__basicsize__", PyMember_GetOne reads it as a
T_INT, which gets it as 0 (incorrect). Accessing it as Py_ssize_t reads it as
16 (correct)
(gdb) p *(Py_ssize_t*)addr
$9 = 16
(gdb) p *(int*)addr
$10 = 0
I'm attaching a patch which changes them to use T_PYSSIZE_T and adds a selftest.
--
keywords: +patch
stage: -> patch review
title: object.__basicsize__ is erroneously0 -> object.__basicsize__ is
erroneously 0 on big-endian 64-bit machines (int vs Py_ssize_t)
type: -> behavior
versions: +Python 2.7
Added file: http://bugs.python.org/file18646/fix-typeobject-T_INT-usage.patch
___
Python tracker
<http://bugs.python.org/issue9688>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8998] add crypto routines to stdlib
Changes by Dave Malcolm : -- nosy: +dmalcolm ___ Python tracker <http://bugs.python.org/issue8998> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9738] Document the encoding of functions bytes arguments of the C API
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: "NUL-terminated buffer of UTF-8-encoded bytes", or whatnot. (sorry for bikeshedding) -- nosy: +dmalcolm ___ Python tracker <http://bugs.python.org/issue9738> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9188] test_gdb fails for UCS2 builds with UCS2 gdb
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/issue9188> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9188] test_gdb fails for UCS2 builds with UCS2 gdb
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.org/issue9188> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9188] test_gdb fails for UCS2 builds with UCS2 gdb
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 reading all that data until it either completes, or hits memory that it can't read (leading to a python exception within gdb). In other places in that code I used safe_range() to limit iterations to a safety threshold; I suggest the use of safety_limit(field_length) But this is a minor nit. I don't think this -- ___ Python tracker <http://bugs.python.org/issue9188> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9188] test_gdb fails for UCS2 builds with UCS2 gdb
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 <http://bugs.python.org/issue9188> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9807] deriving configuration information for different builds with the same prefix
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 Matthias' patch (it was originally based on an
earlier version of Debian's python 2 patch, which I fixed up against Fedora's
python 2, changed some aspects I wasn't happy with, then ported to python 3.1,
then fixed up to 3.2a1 IIRC)
For further reference, Fedora's python3.spec has these comments that I wrote on
the patch:
# Patch to support building both optimized vs debug stacks DSO ABIs, sharing
# the same .py and .pyc files, using "_d.so" to signify a debug build of an
# extension module.
#
# Based on Debian's patch for the same,
#
http://patch-tracker.debian.org/patch/series/view/python2.6/2.6.5-2/debug-build.dpatch
#
# (which was itself based on the upstream Windows build), but with some
# changes:
#
# * Debian's patch to dynload_shlib.c looks for module_d.so, then module.so,
# but this can potentially find a module built against the wrong DSO ABI. We
# instead search for just module_d.so in a debug build
#
# * We remove this change from configure.in's build of the Makefile:
# SO=$DEBUG_EXT.so
# so that sysconfig.py:customize_compiler stays with shared_lib_extension='.so'
# on debug builds, so that UnixCCompiler.find_library_file can find system
# libraries (otherwise "make sharedlibs" fails to find system libraries,
# erroneously looking e.g. for "libffi_d.so" rather than "libffi.so")
#
# * We change Lib/distutils/command/build_ext.py:build_ext.get_ext_filename
# to add the _d there, when building an extension. This way, "make sharedlibs"
# can build ctypes, by finding the sysmtem libffi.so (rather than failing to
# find "libffi_d.so"), and builds the module as _ctypes_d.so
#
# * Similarly, update build_ext:get_libraries handling of Py_ENABLE_SHARED by
# appending "_d" to the python library's name for the debug configuration
#
# * We modify Modules/makesetup to add the "_d" to the generated Makefile
# rules for the various Modules/*.so targets
#
# This may introduce issues when building an extension that links directly
# against another extension (e.g. users of NumPy?), but seems more robust when
# searching for external libraries
#
# * We don't change Lib/distutils/command/build.py: build.build_purelib to
# embed plat_specifier, leaving it as is, as pure python builds should be
# unaffected by these differences (we'll be sharing the .py and .pyc files)
#
# * We introduce DEBUG_SUFFIX as well as DEBUG_EXT:
# - DEBUG_EXT is used by ELF files (names and SONAMEs); it will be "_d" for
# a debug build
# - DEBUG_SUFFIX is used by filesystem paths; it will be "-debug" for a
# debug build
#
# Both will be empty in an optimized build. "_d" contains characters that
# are valid ELF metadata, but this leads to various ugly filesystem paths (such
# as the include path), and DEBUG_SUFFIX allows these paths to have more natural
# names. Changing this requires changes elsewhere in the distutils code.
#
# * We add DEBUG_SUFFIX to PYTHON in the Makefile, so that the two
# configurations build parallel-installable binaries with different names
# ("python-debug" vs "python").
#
# * Similarly, we add DEBUG_SUFFIX within python-config and
# python$(VERSION)-config, so that the two configuration get different paths
# for these.
#
# * Patch runtests.sh to support supplying a value for PYTHON, so that we can
# run the tests against each of the builds
--
___
Python tracker
<http://bugs.python.org/issue9807>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9807] deriving configuration information for different builds with the same prefix
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 this week :( -- ___ Python tracker <http://bugs.python.org/issue9807> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8998] add crypto routines to stdlib
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>). > > Well, similar question: what will it bring and who will do the work? :) > (Fedora perhaps?) Possibly me - if you'll take my patches :) -- ___ Python tracker <http://bugs.python.org/issue8998> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8998] add crypto routines to stdlib
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.org/issue8998> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8998] add crypto routines to stdlib
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 using NSS as an implementation detail) -- ___ Python tracker <http://bugs.python.org/issue8998> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6706] asyncore's accept() is broken
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: sock, addr = self.accept() except TypeError: # sometimes accept() might return None (see issue 91) return except socket.error, err: # ECONNABORTED might be thrown on *BSD (see issue 105) if err[0] != errno.ECONNABORTED: logerror(traceback.format_exc()) return else: # sometimes addr == None instead of (ip, port) (see issue 104) if addr == None: return -- nosy: +dmalcolm ___ Python tracker <http://bugs.python.org/issue6706> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9960] test_structmembers fails on s390x (bigendian 64-bit): int/Py_ssize_t issue
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 "/builddir/build/BUILD/Python-2.7/Lib/test/test_structmembers.py", line 12, in 9.9, 10.1010101010, "hi") ValueError: string too long _testcapimodule.c: test_structmembers_new's fmt has: "s#" and these args: &s, &string_len for grabbing this data: const char *s = NULL; Py_ssize_t string_len = 0; However, the module doesn't define PY_SSIZE_T_CLEAN, which leads to &string_len being treated as an (int*) rather than a (Py_ssize_t*) and thus written to with just the first 32-bits of the size, rather than the full size. The PyArgs_ call without PY_SSIZE_T_CLEAN writes the size of the string (2) through (int*)&string_len, writing 0x0002 to the first 4 bytes, setting the 64-bit "string_len" value to 0x0002 i.e. 2^34, wildly too large for the iirc 5 byte buffer. Confirmed in gdb: (gdb) p string_len $2 = 8589934592 (gdb) p /x string_len $3 = 0x2 Am attaching a patch (against 2.7 maintenance branch) which defines PY_SSIZE_T_CLEAN; doing so requires updating another int to be a Py_ssize_t in that module, within test_u_code. http://docs.python.org/c-api/arg.html lists "u# (Unicode) [Py_UNICODE *, int]" and has no reference to the effect of PY_SSIZE_T_CLEAN on the "u#" format specifier. My reading of Python/getargs.c is that this macro does affect "u#" in a manner analogous to "s#"; does this documentation need clarifying? -- components: Tests files: python-test_structmembers.patch keywords: easy, patch messages: 117448 nosy: dmalcolm priority: normal severity: normal stage: patch review status: open title: test_structmembers fails on s390x (bigendian 64-bit): int/Py_ssize_t issue type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file19029/python-test_structmembers.patch ___ Python tracker <http://bugs.python.org/issue9960> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add Systemtap/DTrace probes
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 - added a test suite: Lib/test/test_systemtap.py - reformatted to use 4-space indentation - slightly reworked the configure.in code Some error-handling issue remain (see the FIXMEs in the code) Tested and working on Fedora 13 x86_64, using: systemtap-1.3-1.fc13.x86_64 kernel-2.6.33.3-84.fc13.x86_64 kernel-devel-2.6.33.3-84.fc13.x86_64 kernel-headers-2.6.33.3-84.fc13.x86_64 kernel-debuginfo-2.6.33.3-84.fc13.x86_64 kernel-debuginfo-common-x86_64-2.6.33.3-84.fc13.x86_64 -- Added file: http://bugs.python.org/file19037/py3k-add-systemtap-2010-09-27.patch ___ Python tracker <http://bugs.python.org/issue4111> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9675] segfault: PyDict_SetItem: Assertion `value' failed.
Changes by Dave Malcolm : -- nosy: +dmalcolm ___ Python tracker <http://bugs.python.org/issue9675> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9518] PyModuleDef_HEAD_INIT does not explicitly initialize all fields of m_base
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 writing out full initializers for PyTypeObject instances (and the other associated structs). It appears to be just Python 3's PyModuleDef_HEAD_INIT macro that leaves fields uninitialized (hence this patch). The gory details of the SWIG-generated code can be seen at: http://userspace.selinuxproject.org/trac/browser/libselinux/src/selinuxswig_wrap.c (and the .i files in that directory) Although it's not on by default gcc will issue a "missing initializer" warning when fields aren't initialized when "-Wmissing-field-initializers" is enabled (in this case, due to the use of "-W"). This becomes an error with -Werror. Whether or not this is a useful warning isn't clear to me, but it seems to be reasonable to suppress the warning given that as-is, people who use gcc's "-W" catch-all will run into this on all Python 3 modules, and that the patch is trivial, and that this case gives no warnings when building such code against Python 2.* Hope this makes sense. -- ___ Python tracker <http://bugs.python.org/issue9518> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8927] Handle version conflicts in dependencies
Dave Abrahams added the comment: I'm not sure the change of title you made is appropriate. The case I described isn't a conflict, in the sense that there is a version of D that satisfies everybody's requirements. Maybe the real title should be something like "exhaustively or comprehensively test dependency resolution." -- ___ Python tracker <http://bugs.python.org/issue8927> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8927] Handle version conflicts in dependencies
Dave Abrahams added the comment: Oh, and http://distutils2.notmyidea.org/depgraph.html is a 404 for me. -- ___ Python tracker <http://bugs.python.org/issue8927> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error
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 wrapper code from Lib/test/test_gdb.py to do this. Test ideas: - generate a segfault, verify that the output is sane - generate a FPE (likewise) - perhaps run all of the crashers, and ensure that something sane happens (e.g. stack overflow when the limit is set to something that's beyond what the OS/CPU can cope with). Also, please test the interaction of this with the debugger (with gdb, at any rate): as I see it, this ought to gracefully get out of the way if you're running python under a debugger. See Lib/test/test_gdb.py for more examples of how to detect gdb, and invoke it in batch mode from a test suite. -- ___ Python tracker <http://bugs.python.org/issue8863> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error
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'd want to avoid breaking them: segfaults of a system-provided /usr/bin/python (or /usr/bin/python3 ) should continue to be detected by such tools. -- ___ Python tracker <http://bugs.python.org/issue8863> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7944] Use the 'with' statement in conjunction with 'open' throughout test modules
Dave Fugate added the comment: I guarantee you that IronPython needs this. I was a tester on IronPython for four years, and saw hundreds of random failures due to this specific issue. My best, Dave -- ___ Python tracker <http://bugs.python.org/issue7944> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add Systemtap/DTrace probes
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://bugs.python.org/issue4111> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error
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 jumps to a broken address; the SIGBUS happens when the CPU tries to fetch the code. -- ___ Python tracker <http://bugs.python.org/issue8863> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7425] [PATCH] Improve the robustness of "pydoc -k" in the face of broken modules
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 containing the extra subdir (and assert no traceback seen in stderr of the child). Does that sound sane? -- ___ Python tracker <http://bugs.python.org/issue7425> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9807] deriving configuration information for different builds with the same prefix
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 (distutils.tests.test_build_ext.BuildExtTestCase) ... /usr/bin/ld: cannot find -lpython3.2 collect2: ld returned 1 exit status Each build makes a "libpython3.2.a" -- ___ Python tracker <http://bugs.python.org/issue9807> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10140] Tools/scripts/pathfix.py: add option to preserve timestamps
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 attaching a patch to the py3k branch which adds a "-p" option to the Tools/script/pathfix.py script, which makes it preserve the mtime of the input files. -- components: Build files: pathfix-preserve-timestamps.patch keywords: needs review, patch messages: 119092 nosy: dmalcolm priority: normal severity: normal stage: patch review status: open title: Tools/scripts/pathfix.py: add option to preserve timestamps type: feature request versions: Python 3.2 Added file: http://bugs.python.org/file19276/pathfix-preserve-timestamps.patch ___ Python tracker <http://bugs.python.org/issue10140> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add Systemtap/DTrace probes
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 | 75 + configure | 576 +++-- configure.in | 34 ++ pyconfig.h.in |3 7 files changed, 522 insertions(+), 275 deletions(-) Patch contains FIXMEs (sorry), which clearly need addressing. As for the objectives, do folks here agree with the "Performance" notes in http://bugs.python.org/issue4111#msg100173 ? -- Added file: http://bugs.python.org/file19358/py3k-add-systemtap-2010-10-25.patch ___ Python tracker <http://bugs.python.org/issue4111> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add Systemtap/DTrace probes
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 confuse the regular exception handling within ceval. I'm not sure how to write a unit test to test for this: perhaps we could corrupt the __code__ instance so that co_filename is not a PyUnicodeObject, leading to a TypeError within the function, but that's a readonly attribute. Any ideas? I've also added a unit test for a non-ASCII script (Lib/test/systemtap_sample_☠.py), containing a non-ASCII identifier (文字化け). The non-ASCII script name (Lib/test/systemtap_sample_☠.py) may be controversial: do we have anything like that in the source tree yet? Is there any risk of messing up the build across platforms, or of impacting the Hg migration? Still to-do: - address the "Undefined symbol" issues seen by jcea. - documentation - doublecheck performance -- Added file: http://bugs.python.org/file19360/py3k-add-systemtap-2010-10-25-002.patch ___ Python tracker <http://bugs.python.org/issue4111> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add Systemtap/DTrace probes
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_☠.py, and now generate a similarly-named file during the test, using test.support.TEST_FN and unlink Still TODO: - address pitrou's concerns about PyUnicode_AsUTF8String from msg119580 - address the "Undefined symbol" issues seen by jcea (msg119563 onwards) - documentation - doublecheck performance - perhaps add a systemtap "tapset", and demo code using it (like I did in Fedora's python3 RPMs) - anything else I've missed :) -- Added file: http://bugs.python.org/file19363/py3k-add-systemtap-2010-10-25-003.patch ___ Python tracker <http://bugs.python.org/issue4111> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4111] Add Systemtap/DTrace probes
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 with systemtap, fwiw). Are there any DTrace experts around who would be willing to handle the DTrace side of this? If not, would it be reasonable to make this issue be only explicitly about "systemtap"? (e.g. perhaps change the "configure" argument accordingly?) Alternatively, given that this bug originally started as an RFE about DTrace, should we split out systemtap as a separate RFE? I'm sorry if I've "muddied the waters" by doing this. For example, the only test coverage I've written (test_systemtap.py) checks for the presence of a "stap" executable, and skips the tests if it's not found. I'm not familiar enough with DTrace to create the same for DTrace. FWIW (in response to IRC question): "thread_indent" is documented here: http://sourceware.org/systemtap/SystemTap_Beginners_Guide/systemtapscript-handler.html#thread_indent It looks like it may be systemtap-specific; however the only usage is within test_systemtap.py, guarded by the presence of a "stap" binary, skipping the tests if it is not found. -- ___ Python tracker <http://bugs.python.org/issue4111> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10195] Memory allocation fault-injection?
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 allocations in the future: >>> import sys [52733 refs] >>> 2 + 2 4 [52733 refs] >>> sys._inject_malloc_failure(50) [52733 refs] >>> 2 + 2 MemoryError [52747 refs] >>> 2 + 2 4 [52747 refs] I'm not sure how to make this useful; perhaps it could instead compare with the "serialno" in Objects/obmalloc.c so that you could set up a specific numbered allocation and have it fail (or perhaps a range of serial numbers, and expose "serialno" within the "sys" module?) Another idea might be to randomly have some proportion of allocations fail. Perhaps the test suite could have an option where it runs each set of tests in a separate subprocess, and sets a command-line switch to inject "random" malloc failures? (storing the seed, so that they're reproducible, on one machine at least). -- components: Tests files: py3k-inject-malloc-failure.txt messages: 119586 nosy: dmalcolm, pitrou priority: normal severity: normal status: open title: Memory allocation fault-injection? type: feature request versions: Python 3.2 Added file: http://bugs.python.org/file19365/py3k-inject-malloc-failure.txt ___ Python tracker <http://bugs.python.org/issue10195> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10195] Memory allocation fault-injection?
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 afterwards.
I used this to find a specific bug in Python/pythonrun.c (fix is the first hunk
of the patch): if moduleName is NULL, then Py_DECREF will read through NULL.
Potentially this gives the low-level machinery to support adding SQLite's
approach to be added to regrtest. Doing so would imply running each test many
tens of thousands of times, so perhaps we could run "-c pass" to establish at
what serialno the interpreter has fully started up, then use that as a starting
point when testing other scripts/modules.
I implemented a toy version of this as Lib/test/test_malloc_fault.py, which
sits in an infinite loop injecting individual allocation failures when starting
up sys.executable as a subprocess.
For low numbers, this throws up segfaults within _Py_ReadyTypes' call to
PyType_Ready(&PyType_Type), where PyExc_MemoryError is set but has not yet been
initialized (its ob_type is NULL):
/* this will probably fail since there's no memory and hee,
hee, we have to instantiate this class
*/
Running this interactively with a large value for PYTHONMALLOCINJECTFAULTSAT
leads to an interesting failure mode within PyRun_InteractiveLoopFlags(): every
call to PyRun_InteractiveOneFlags immediately returns (the
PyUnicode_FromString("stdin") in within PySys_GetObject() fails to allocate
memory); this leads to a tight loop sending the total refcount to stderr:
[52812 refs]
[52812 refs]
[52812 refs]
(etc)
--
Added file: http://bugs.python.org/file19372/py3k-inject-malloc-failure-002.txt
___
Python tracker
<http://bugs.python.org/issue10195>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9942] Allow memory sections to be OS MERGEABLE
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 allocation from the object, and thus isn't subjected to the ob_refcnt twiddling. No idea if it's worth it though; the syscall overhead might slow down module import; also, KSM works at the level of 4K pages, and it's not clear that the allocations would line up nicely with pages. FWIW, various related ideas here: http://dmalcolm.livejournal.com/4183.html Again, no idea if these are worthwhile, this was a brainstorm on my blog, and some of the ideas would involve major surgery to CPython to implement. -- nosy: +dmalcolm ___ Python tracker <http://bugs.python.org/issue9942> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1346238] A constant folding optimization pass for the AST
Changes by Dave Malcolm : -- nosy: +dmalcolm ___ Python tracker <http://bugs.python.org/issue1346238> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9635] Add Py_BREAKPOINT and sys.breakpoint hooks
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/py3k-add-breakpoint-2010-11-01-001.patch ___ Python tracker <http://bugs.python.org/issue9635> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
