from:"aaron"


Changes by Aaron Iles aaron.i...@gmail.com:


--
nosy: +aliles

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15475
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13266] Add inspect.unwrap(f) to easily unravel wrapped chains


Changes by Aaron Iles aaron.i...@gmail.com:


--
nosy: +aliles

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13266
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15490] Correct sizeof support for StringIO


Changes by Aaron Iles aaron.i...@gmail.com:


--
nosy: +aliles

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15490
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15436] sizeof is not documented


Changes by Aaron Iles aaron.i...@gmail.com:


--
nosy: +aliles

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15436
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15696] Correct sizeof support for mmap


Changes by Aaron Iles aaron.i...@gmail.com:


--
nosy: +aliles

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15696
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15695] Correct sizeof support for StgDict


Changes by Aaron Iles aaron.i...@gmail.com:


--
nosy: +aliles

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15695
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15513] Correct sizeof support for pickle


Changes by Aaron Iles aaron.i...@gmail.com:


--
nosy: +aliles

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15513
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12403] Mention sys.displayhook in code module docs and the compile builtin docs

2012-08-27 Thread Aaron Iles


Aaron Iles added the comment:

I've submitted a patch which adds a section to the code module's documentation 
on overriding console output. It attempts to catalogue when sys.stderr, 
sys.excepthook and sys.displayhook are used to print console output.

--
keywords: +patch
nosy: +aliles
Added file: http://bugs.python.org/file27014/p1346072775.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12403
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15762] Windows 8 certification

2012-08-24 Thread Aaron Galea


Aaron Galea added the comment:

Its a distutils issue not py2exe. Not sure where I should post about this 
problem. 

The change I applied was in msvc9compiler.py in distutils. Once this change has 
been applied py2exe was rebuild to generate the correct runw.exe with the 
correct settings in the PE header of the executable.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15762
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15762] Windows 8 certification

2012-08-22 Thread Aaron Galea


New submission from Aaron Galea:

Hi

We have an application created with python2.7 and created into an executable 
using py2exe. However we are getting an issue with Windows 8 certification due 
to compiler parameters. We would like to have this application Windows 8 
certified but we can't get pass the following warning:
===
Windows security features test 


WARNING 
Binary analyzer
•
Warning: The binary analyzer test detected the following errors: 
◦File C:\Program Files (x86)\TestApp\test.exe has failed the DBCheck check.
◦File C:\Program Files (x86)\TestApp\test.exe has failed the NXCheck check.

•
Impact if not fixed: If the app doesn’t use the available Windows protections, 
it can increase the vulnerability of customer's computer to malware. 

•
How to fix: Apply the SAFESEH, DYNAMICBASE, and NXCOMPAT options when you link 
the app. See link below for more information:
Fixing Binary Analyzer Errors 



In order to fix this issue I had to modify the file msvc9compiler.py by 
changing the following line from:

self.ldflags_shared = ['/DLL', '/nologo', '/INCREMENTAL:NO']

to

self.ldflags_shared = ['/DLL', '/nologo', '/INCREMENTAL:NO', '/DYNAMICBASE', 
'/SAFESEH', '/NXCOMPAT']

and rebuild py2exe. Once I have done this the test passed.

I could go about it by having local patch available to my team but preferably I 
try to avoid patching the standard python modules.

My question is if there is another way to do this? and whether it would be a 
good idea to include these flags in future distutils?

--
assignee: eric.araujo
components: Distutils
messages: 168859
nosy: agale031176, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: Windows 8 certification
type: enhancement
versions: Python 2.7

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15762
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15542] Documentation incorrectly suggests init called after direct new call

2012-08-02 Thread Aaron Staley


New submission from Aaron Staley:

The documentation for __new__ at 
http://docs.python.org/reference/datamodel.html#object.__new__ is:

object.__new__(cls[, ...])
Called to create a new instance of class cls. __new__() is a static method 
(special-cased so you need not declare it as such) that takes the class of 
which an instance was requested as its first argument. The remaining arguments 
are those passed to the object constructor expression (the call to the class). 
The return value of __new__() should be the new object instance (usually an 
instance of cls).

Typical implementations create a new instance of the class by invoking the 
superclass’s __new__() method using super(currentclass, cls).__new__(cls[, 
...]) with appropriate arguments and then modifying the newly-created instance 
as necessary before returning it.

If __new__() returns an instance of cls, then the new instance’s __init__() 
method will be invoked like __init__(self[, ...]), where self is the new 
instance and the remaining arguments are the same as were passed to __new__().

If __new__() does not return an instance of cls, then the new instance’s 
__init__() method will not be invoked.

__new__() is intended mainly to allow subclasses of immutable types (like int, 
str, or tuple) to customize instance creation. It is also commonly overridden 
in custom metaclasses in order to customize class creation.



The problem is in this line: If __new__() returns an instance of cls, then the 
new instance’s __init__() method will be invoked like __init__(self[, ...]), 
where self is the new instance and the remaining arguments are the same as were 
passed to __new__().

This is only true in the context of a constructor. In particular, directly 
calling cls.__new__(cls) will NOT call __init__.

If I define a class:
  
class C(object):
  def __new__(*args, **kwargs):
print 'new', args, kwargs
return object.__new__(*args,**kwargs)
  def __init__(self):
print 'init'

C() will result in __new__ and __init__ being both executed, but C.__new__(C) 
will only create the instance of C; it will not call __init__!

The original documentation described in http://bugs.python.org/issue1123716 was 
more correct:

__new__ must return an object... If you return an
existing object, the constructor call will still call
its __init__ method unless the object is an instance of
a different class...

That is __init__ is only being called in the context of an external constructor 
call.  

Proposed phrasing:
If __new__() is invoked during object construction (cls()) and it returns an 
instance of cls, then the new instance’s __init__() method will be invoked like 
__init__(self[, ...]), where self is the new instance and the remaining 
arguments are the same as were passed to the object constructor.

--
assignee: docs@python
components: Documentation
messages: 167267
nosy: Aaron.Staley, docs@python
priority: normal
severity: normal
status: open
title: Documentation incorrectly suggests __init__ called after direct  __new__ 
call
versions: Python 2.7

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15542
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4640] optparse doesn’t disallow adding one-dash long options (“-option”)

2012-07-09 Thread Aaron


Aaron hacm...@gmail.com added the comment:

I came across this bug report and was unable to reproduce the described 
behavior.  I wrote a few test cases demonstrating that the behavior is indeed 
correct.  It passes both against 2.5.2 (the version described in the report) 
and the lastest 2.7.

The relevant code is line 602 of optparse.py in the function 
Option._set_opt_strings().

I believe this bug can be closed.

--
keywords: +patch
nosy: +hac.man
Added file: http://bugs.python.org/file26338/test_optparse.py.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4640
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14938] 'import my_pkg.init' creates duplicate modules

2012-05-28 Thread Aaron Meurer


Changes by Aaron Meurer asmeu...@gmail.com:


--
nosy: +Aaron.Meurer

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14938
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14877] No option to run bdist_wininst against newer msvc versions on non-windows systems

2012-05-24 Thread Aaron Staley


Aaron Staley usaa...@gmail.com added the comment:

Hi Eric,

Quick rundown: There are template 'exe' inside distutils/command.  
bdist_wininst appends to the template to build a customized installer.

First the 64 bit bug:
http://bugs.python.org/issue6792

With that bug active, I must be able to make 64 bit windows installers for 
users of 64 bit windows python to install my package.  Unfortunately, the only 
64 bit template is wininst-9.0-amd64.exe. Due to this bug, there is no way to 
use that installer, preventing one from creating universal windows installers 
on *nix, which bdist_wininst is supposed to allowed (per documentaiton).

Furthermore, I have empirically found that a 32-bit installer built against 
wininst-6.0 will not behave correctly either. Specifically, the 
pre-install-script I used would not execute.  When I switched to the 
wininst-9.0 template, all worked fine.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14877
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14877] No option to run bdist_wininst against newer msvc versions on non-windows systems

2012-05-21 Thread Aaron Staley


New submission from Aaron Staley usaa...@gmail.com:

On a *nix system, bdist_wininst.get_exe_bytes will always return an open  
wininst-6.0.exe.

However, Windows python2.7 is compiled against msvc 9.0 and ideally would take 
an installer based on wininst-9.0.exe.  Windows-64bit needs an installer based 
on wininst-9.0-amd64.exe.

The ideal solution would be for bdist_wininst to take an option what template 
exe to be used. While I've monkey-patched things on my own, I'm not providing 
a patch as I'm not sure how the community wants to handle this (it could be 
anywhere from the exe name to tables being driven by target_version and some 
some 64bit option)

--
assignee: eric.araujo
components: Distutils
messages: 161313
nosy: Aaron.Staley, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: No option to run bdist_wininst against newer msvc versions on 
non-windows systems
versions: Python 2.7

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14877
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14877] No option to run bdist_wininst against newer msvc versions on non-windows systems

2012-05-21 Thread Aaron Staley


Aaron Staley usaa...@gmail.com added the comment:

Sorry, minor correction: We could just rely on plat_name for 64bit.

All that is needed is for this table:


if self.target_version  2.4:
bv = 6.0
else:
bv = 7.1


to be updated to python2.7  (9.0 for python2.7)

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14877
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8954] wininst regression: errors when building on linux

2012-05-21 Thread Aaron Staley


Aaron Staley usaa...@gmail.com added the comment:

I was looking over this patch (as it relates to my bug report: 
http://bugs.python.org/issue14877?@ok_message=msg%20161314%20created%3Cbr%3Eissue%2014877%20message_count%2C%20messages%20edited%20ok@template=item)
 and noticed that this line:

+if (not self.distribution.has_ext_modules() and 
+not self.distribution.has_c_libraries()):
+basename = %s.%s % (fullname, win32)

I feel it may be better to insert plat_name there if it exists. That way, users 
can create installers targeted for win-amd64.  Why is this needed for a pure 
python packages? This bug: http://bugs.python.org/issue6792

--
nosy: +Aaron.Staley

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8954
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14573] json iterencode can not handle general iterators

2012-04-13 Thread Aaron Staley


New submission from Aaron Staley usaa...@gmail.com:

The json library's encoder includes a function called 'iterencode'.  iterencode 
allows for encoding to be streamed; as tokens are produced they are yielded. 
This allows for the encoded object to be streamed to a file, over a socket, 
etc. without being placed all into memory.

Unfortunately, iterencode cannot encode general iterators.  This significantly 
limits the usefulness of the function.  For my use case I wish to convert a 
large stream (iterator) of objects into json.  Unfortunately, I currently have 
to:

A. Bring all the objects into memory by encasing the iterator in a list()
B. Make a hack where I subclass list and making that object's __iter__ function 
return my desired iterator.

The problem is that the json library explicitly checks for something being a 
list:

if isinstance(value, (list, tuple)):
chunks = _iterencode_list(value, _current_indent_level)

It would work just as well (and be more pythonic) to see if the value supports 
the iterator protocol:
if isinstance(value, collections.Iterable):
chunks = _iterencode_list(value, _current_indent_level)


Erroring example:

 import json
 e = json.JSONEncoder()
 r = xrange(20)
 gen = e.iterencode(r)
generator object _iterencode at 0x14a5460
 next(gen)

Traceback (most recent call last):
  File stdin, line 1, in module
  File /usr/lib/python3.2/json/encoder.py, line 419, in _iterencode
o = _default(o)
  File /usr/lib/python3.2/json/encoder.py, line 170, in default
raise TypeError(repr(o) +  is not JSON serializable)
TypeError: xrange(0, 20) is not JSON serializable

--
components: Library (Lib)
messages: 158239
nosy: Aaron.Staley
priority: normal
severity: normal
status: open
title: json iterencode can not handle general iterators
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14573
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14537] Fatal Python error: Cannot recover from stack overflow. with SymPy test suite

2012-04-09 Thread Aaron Meurer

New submission from Aaron Meurer asmeu...@gmail.com:

Recently, after a small seemingly unrelated refactoring, the SymPy test suite
in Python 3 started dying with Fatal Python error: Cannot recover from stack
overflow.

Here's how to reproduce the error

git clone git://github.com/sympy/sympy.git # Clone the development version of
SymPy
cd sympy
git checkout 0856119bd7399a416c21e1692855a1077164f21c # This is the first
commit to exhibit the problem. Do this in case we make an unrelated change that
removes the problem.
./bin/use2to3 # Convert the codebase to Python 3
python3 py3k-sympy/setup.py test # Run the tests

The issue is described in more detail at
http://groups.google.com/group/sympy/browse_thread/thread/f664fe88e6b4f29d/3a44691c945695db#3a44691c945695db.
Some key points:

- The test that triggers the error is an XFAIL test (test that is expected to
fail) that raises RuntimeError: maximum recursion depth exceeded.

- The change that caused the error, 0856119bd7399a416c21e1692855a1077164f21c
(see
https://github.com/sympy/sympy/commit/0856119bd7399a416c21e1692855a1077164f21c),
is seemingly unrelated. The only thing that I can think of is that it has
added another call to the stack.

- This kills Python with Abort Trap: 6 in Mac OS X, which generates a problem
report to be sent to Apple. I have included a copy of it here:
https://gist.github.com/2317869.

- Others have reproduced this error as well, as can be seen by our test
reporter tool. See the mailing list thread for more info.

- I tested this in 3.2.3r2, and the error still occurred. I tried testing in
the 3.3 alpha, but I could not get it to compile.

--
messages: 157876
nosy: Aaron.Meurer
priority: normal
severity: normal
status: open
title: Fatal Python error: Cannot recover from stack overflow. with SymPy
test suite
type: crash
versions: Python 3.2

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14537
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14537] Fatal Python error: Cannot recover from stack overflow. with SymPy test suite

2012-04-09 Thread Aaron Meurer


Aaron Meurer asmeu...@gmail.com added the comment:

We do have a stack overflow, but this should be raising a RuntimeError, not 
killing Python.  The way it is now, Python dies completely with abort trap 6 
(hence the Mac OS X problem report).  Sorry if I didn't make this clear in the 
OP.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14537
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14537] Fatal Python error: Cannot recover from stack overflow. with SymPy test suite

2012-04-09 Thread Aaron Meurer


Aaron Meurer asmeu...@gmail.com added the comment:

No it does not.  SymPy is a pure Python library.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14537
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13992] Segfault in PyTrash_destroy_chain

2012-02-13 Thread Aaron Staley


Aaron Staley usaa...@gmail.com added the comment:

Unfortunately, my application is running so slow under valgrind that behavior 
is changing, namely the sockets are all timing out.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13992
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13992] Segfault in PyTrash_destroy_chain

2012-02-13 Thread Aaron Staley


Aaron Staley usaa...@gmail.com added the comment:

I see no invalid read/write. Only warnings are some conditional jump depends on 
uninitialized value in pycrypto's libraries very early on though.

The link seems to be a different bug from mine.  I did test in python 2.6.7 and 
the crash still occurs.  (I also never get a segfault on my system with the 
link's test case - perhaps that only occurs in osx?)

To do the async exception, I use ctypes.pythonapi.PyThreadState_SetAsyncExc in 
python itself.  This is relatively rarely used however.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13992
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13992] Segfault in PyTrash_destroy_chain

2012-02-13 Thread Aaron Staley


Aaron Staley usaa...@gmail.com added the comment:

BTW, I take back what I said about using PyThreadState_SetAsyncExc.  Turns out 
I had a bug where this function would never succeed (was always returning 0).

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13992
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13992] Segfault in PyTrash_destroy_chain


Aaron Staley usaa...@gmail.com added the comment:

Active extension modules are MySQL-python, numpy, and crypto.

Here is the output from the non-optimized debug build. Slightly different 
trace, but still some sort of deallocator crashing AFAIK:


#0  0x0046247c in _Py_ForgetReference (op=
Channel(origin_addr=None, in_window_size=65536, in_window_threshold=6553, 
lock=thread.lock at remote 0x571bf90, _pipe=None, eof_received=0, 
in_max_packet_size=34816, out_buffer_cv=_Condition(_Verbose__verbose=False, 
_Condition__lock=thread.lock at remote 0x571bf90, acquire=built-in method 
acquire of thread.lock object at remote 0x571bf90, _Condition__waiters=[], 
release=built-in method release of thread.lock object at remote 0x571bf90) at 
remote 0x593d3e0, event=_Event(_Verbose__verbose=False, _Event__flag=True, 
_Event__cond=_Condition(_Verbose__verbose=False, _Condition__lock=thread.lock 
at remote 0x59138b0, acquire=built-in method acquire of thread.lock object at 
remote 0x59138b0, _Condition__waiters=[], release=built-in method release of 
thread.lock object at remote 0x59138b0) at remote 0x5a333e0) at remote 
0x593ded0, transport=Transport(_Thread__ident=140009885591296, 
host_key_type='ssh-rsa', _channels=ChannelMap(_lock=thread.lock at remote 
0x5928f90,
  _map=WeakValueDictionary(_re...(truncated)) at Objects/object.c:2220
#1  0x004624ed in _Py_Dealloc (op=
Channel(origin_addr=None, in_window_size=65536, in_window_threshold=6553, 
lock=thread.lock at remote 0x571bf90, _pipe=None, eof_received=0, 
in_max_packet_size=34816, out_buffer_cv=_Condition(_Verbose__verbose=False, 
_Condition__lock=thread.lock at remote 0x571bf90, acquire=built-in method 
acquire of thread.lock object at remote 0x571bf90, _Condition__waiters=[], 
release=built-in method release of thread.lock object at remote 0x571bf90) at 
remote 0x593d3e0, event=_Event(_Verbose__verbose=False, _Event__flag=True, 
_Event__cond=_Condition(_Verbose__verbose=False, _Condition__lock=thread.lock 
at remote 0x59138b0, acquire=built-in method acquire of thread.lock object at 
remote 0x59138b0, _Condition__waiters=[], release=built-in method release of 
thread.lock object at remote 0x59138b0) at remote 0x5a333e0) at remote 
0x593ded0, transport=Transport(_Thread__ident=140009885591296, 
host_key_type='ssh-rsa', _channels=ChannelMap(_lock=thread.lock at remote 
0x5928f90,
  _map=WeakValueDictionary(_re...(truncated)) at Objects/object.c:2240
#2  0x00442244 in list_dealloc (op=0x66d7ab0) at 
Objects/listobject.c:309
#3  0x004624fa in _Py_Dealloc (op=
[Channel(origin_addr=None, in_window_size=65536, in_window_threshold=6553, 
lock=thread.lock at remote 0x571bf90, _pipe=None, eof_received=0, 
in_max_packet_size=34816, out_buffer_cv=_Condition(_Verbose__verbose=False, 
_Condition__lock=thread.lock at remote 0x571bf90, acquire=built-in method 
acquire of thread.lock object at remote 0x571bf90, _Condition__waiters=[], 
release=built-in method release of thread.lock object at remote 0x571bf90) at 
remote 0x593d3e0, event=_Event(_Verbose__verbose=False, _Event__flag=True, 
_Event__cond=_Condition(_Verbose__verbose=False, _Condition__lock=thread.lock 
at remote 0x59138b0, acquire=built-in method acquire of thread.lock object at 
remote 0x59138b0, _Condition__waiters=[], release=built-in method release of 
thread.lock object at remote 0x59138b0) at remote 0x5a333e0) at remote 
0x593ded0, transport=Transport(_Thread__ident=140009885591296, 
host_key_type='ssh-rsa', _channels=ChannelMap(_lock=thread.lock at remote 
0x5928f90
 , _map=WeakValueDictionary(_r...(truncated)) at Objects/object.c:2241
#4  0x00448bc4 in listiter_next (it=0x5d1c530) at 
Objects/listobject.c:2917
#5  0x004ce425 in PyEval_EvalFrameEx (f=
Frame 0x7f56a050aea0, for file 
/usr/lib/python2.7/dist-packages/paramiko/transport.py, line 1586, in run 
(self=Transport(_Thread__ident=140009885591296, host_key_type='ssh-rsa', 
_channels=ChannelMap(_lock=thread.lock at remote 0x5928f90, 
_map=WeakValueDictionary(_remove=function at remote 0x56355a0, data={}) at 
remote 0x5939588) at remote 0x5912bc0, lock=thread.lock at remote 
0x5928d60, _Thread__started=_Event(_Verbose__verbose=False, 
_Event__flag=True, _Event__cond=_Condition(_Verbose__verbose=False, 
_Condition__lock=thread.lock at remote 0x521ff40, acquire=built-in method 
acquire of thread.lock object at remote 0x521ff40, _Condition__waiters=[], 
release=built-in method release of thread.lock object at remote 0x521ff40) at 
remote 0x5223300) at remote 0x47f56f0, _channel_counter=22, active=False, 
_preferred_compression=('none',), server_object=None, kex_engine=None, 
log_name='paramiko.transport', _x11_handler=None, remote_compression='none', 
_Thread__initiali
 zed=True, server_accepts=[], s...(truncated), throwflag=0) at 
Python/ceval.c:2497
#6  0x004d41c3 in fast_function (func=function at remote 0x4716300, 
pp_stack=0x7f56977ed400, n=1, na=1, nk=0) at Python/ceval.c:4099
#7

[issue13992] Segfault in PyTrash_destroy_chain


Aaron Staley usaa...@gmail.com added the comment:

As far as I can tell, no other thread is active.  Their backtraces are all 
either:


#0  0x7f283dedd300 in sem_wait () from /lib/x86_64-linux-gnu/libpthread.so.0
#1  0x00519295 in PyThread_acquire_lock (lock=0xe7dd50, waitflag=1) at 
Python/thread_pthread.h:321
#2  0x004c734f in PyEval_RestoreThread (tstate=0xfbfb40) at 
Python/ceval.c:357


or

Thread 77 (Thread 0x7f2808fb1700 (LWP 30292)):
#0  0x7f283d57a773 in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7f283c458739 in internal_select (s=0x7f2831432ca0, writing=0) at 
/root/python2.7-2.7.2/Modules/socketmodule.c:692
#2  0x7f283c45acdf in sock_recv_guts (s=0x7f2831432ca0, cbuf=0x339bf7c 
\313\313\313\313\313\313\313\313\313\313\313\313\313\313\313, incomplete 
sequence \313, len=16, flags=0) at 
/root/python2.7-2.7.2/Modules/socketmodule.c:2356
(More stack frames follow...)

or

Thread 17 (Thread 0x7f2829ff3700 (LWP 19252)):
#0  0x7f283d57f913 in select () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7f283d2a1fac in floatsleep (secs=0) at 
/root/python2.7-2.7.2/Modules/timemodule.c:943
#2  0x7f283d2a0cd9 in time_sleep (self=0x0, args=(float at remote 
0xb3ed40,)) at /root/python2.7-2.7.2/Modules/timemodule.c:206
(More stack frames follow...)

or
Thread 12 (Thread 0x7f2834e5f700 (LWP 19223)):
#0  0x7f283d57f913 in select () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7f2839cb275e in select_select (self=0x0, args=([_socketobject at 
remote 0x7f2830f4d1a0, _socketobject at remote 0x2106ec0], [], [], float at 
remote 0x7f283034d510)) at /root/python2.7-2.7.2/Modules/selectmodule.c:278
#2  0x0055f0ee in PyCFunction_Call (func=built-in function select, 
arg=([_socketobject at remote 0x7f2830f4d1a0, _socketobject at remote 
0x2106ec0], [], [], float at remote 0x7f283034d510), kw=0x0) at 
Objects/methodobject.c:81
(More stack frames follow...)


Unfortunately, I've only been able to produce the segfault with this program 
(an EC2 server monitor and deployer).  It's very site specific and couldn't run 
on another machine.

That said, I can trigger these segfaults with high reliability, so I can 
certainly add additional debugging logs if requested.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13992
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13992] Segfault in PyTrash_destroy_chain


Aaron Staley usaa...@gmail.com added the comment:

I should note that my program is also affected by this bug:
http://bugs.python.org/issue13817
(couldn't isolate it until I used the pydebug configure info).

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13992
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13992] Segfault in PyTrash_destroy_chain


Aaron Staley usaa...@gmail.com added the comment:

Used latest mercurial 2.7 branch and segfault still occurs.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13992
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13992] Segfault in PyTrash_destroy_chain


Aaron Staley usaa...@gmail.com added the comment:

Also, the only particular things by code does is have a lot of threads (100+), 
holds open many ssh connections (with paramiko) and I do occasionally use 
PyThreadState_SetAsyncExc to asynchronously terminate threads.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13992
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13992] Segfault in PyTrash_destroy_chain

2012-02-11 Thread Aaron Staley


New submission from Aaron Staley usaa...@gmail.com:

Am frequently getting segmentation faults with my python program.  I am 
utilizing heavy use of threading and sockets.

All sorts of ones are showing in syslog:

kernel: [7763578.475590] python[10097]: segfault at 88e5a0 ip 0088e5a0 
sp 7f640efd4028 error 15 in python2.7[833000+69000]
Feb 11 11:39:41 ip-10-8-197-187 kernel: [7762910.806782] python[6228]: segfault 
at 16 ip 0016 sp 7fe488fb0028 error 14 in 
python2.7[40+233000]
Feb 11 07:36:09 ip-10-8-197-187 kernel: [7748298.747145] python[11376]: 
segfault at 16 ip 0016 sp 7f28767ab028 error 14 in 
python2.7[40+233000]

Managed to capture one coredump:

Program terminated with signal 11, Segmentation fault.
#0  0x0009 in ?? ()
(gdb) where
#0  0x0009 in ?? ()
#1  0x0046670f in _PyTrash_destroy_chain () at ../Objects/object.c:2448
#2  0x004bd0df in PyEval_EvalCodeEx (co=optimized out, 
globals=optimized out, locals=optimized out, args=optimized out, 
argcount=optimized out, kws=optimized out, kwcount=0, defs=0x0, defcount=0, 
closure=
(cell at remote 0x293ef68, cell at remote 0x21c78d8, cell at remote 
0x239e168, cell at remote 0x219ef30, cell at remote 0x2397a28, cell at 
remote 0x2129868, cell at remote 0x2397590, cell at remote 0x2397be8, 
cell at remote 0x2397fa0)) at ../Python/ceval.c:3264
#3  0x004b6a5b in fast_function (nk=optimized out, na=0, n=optimized 
out, pp_stack=0x7f778ef9c1b0, func=function at remote 0x20afa28) at 
../Python/ceval.c:4117
#4  call_function (oparg=optimized out, pp_stack=0x7f778ef9c1b0) at 
../Python/ceval.c:4042
#5  PyEval_EvalFrameEx (f=optimized out, throwflag=optimized out) at 
../Python/ceval.c:2666
#6  0x004bcd2d in PyEval_EvalCodeEx (co=0x168f6b0, globals=optimized 
out, locals=optimized out, args=optimized out, argcount=optimized out, 
kws=optimized out, kwcount=0, defs=0x169f260, defcount=2, closure=
0x0) at ../Python/ceval.c:3253
#7  0x004b6a5b in fast_function (nk=optimized out, na=3, n=optimized 
out, pp_stack=0x7f778ef9c3a0, func=function at remote 0x16a00c8) at 
../Python/ceval.c:4117
#8  call_function (oparg=optimized out, pp_stack=0x7f778ef9c3a0) at 
../Python/ceval.c:4042
#9  PyEval_EvalFrameEx (f=optimized out, throwflag=optimized out) at 
../Python/ceval.c:2666
#10 0x004bd325 in PyEval_EvalCodeEx (co=0x168f8b0, globals=optimized 
out, locals=optimized out, args=optimized out, argcount=optimized out, 
kws=optimized out, kwcount=5, defs=0x169a6c8, defcount=5, closure=
0x0) at ../Python/ceval.c:3253
#11 0x004b6a5b in fast_function (nk=optimized out, na=1, n=optimized 
out, pp_stack=0x7f778ef9c590, func=function at remote 0x16a0140) at 
../Python/ceval.c:4117
#12 call_function (oparg=optimized out, pp_stack=0x7f778ef9c590) at 
../Python/ceval.c:4042
#13 PyEval_EvalFrameEx (f=optimized out, throwflag=optimized out) at 
../Python/ceval.c:2666
#14 0x004bcd2d in PyEval_EvalCodeEx (co=0x168a130, globals=optimized 
out, locals=optimized out, args=optimized out, argcount=optimized out, 
kws=optimized out, kwcount=0, defs=0x1684d28, defcount=1, closure=
0x0) at ../Python/ceval.c:3253
#15 0x004b6a5b in fast_function (nk=optimized out, na=2, n=optimized 
out, pp_stack=0x7f778ef9c780, func=function at remote 0x1763758) at 
../Python/ceval.c:4117
#16 call_function (oparg=optimized out, pp_stack=0x7f778ef9c780) at 
../Python/ceval.c:4042
#17 PyEval_EvalFrameEx (f=optimized out, throwflag=optimized out) at 
../Python/ceval.c:2666
#18 0x004b6d77 in fast_function (nk=optimized out, na=optimized 
out, n=optimized out, pp_stack=0x7f778ef9c8c0, func=function at remote 
0x1ebf050) at ../Python/ceval.c:4107
#19 call_function (oparg=optimized out, pp_stack=0x7f778ef9c8c0) at 
../Python/ceval.c:4042
#20 PyEval_EvalFrameEx (f=optimized out, throwflag=optimized out) at 
../Python/ceval.c:2666
#21 0x004b6d77 in fast_function (nk=optimized out, na=optimized 
out, n=optimized out, pp_stack=0x7f778ef9ca00, func=function at remote 
0xc5f5f0) at ../Python/ceval.c:4107
#22 call_function (oparg=optimized out, pp_stack=0x7f778ef9ca00) at 
../Python/ceval.c:4042
#23 PyEval_EvalFrameEx (f=optimized out, throwflag=optimized out) at 
../Python/ceval.c:2666
#24 0x004bcd2d in PyEval_EvalCodeEx (co=0xc0d9b0, globals=optimized 
out, locals=optimized out, args=optimized out, argcount=optimized out, 
kws=optimized out, kwcount=0, defs=0x0, defcount=0, closure=0x0)
at ../Python/ceval.c:3253
#25 0x00448edf in function_call (func=function at remote 0xc5f500, 
arg=
(ProvisionThread(_Thread__ident=140151476573952, 
_Thread__block=_Condition(_Verbose__verbose=False, 
_Condition__lock=thread.lock at remote 0x33d2fd0, acquire=built-in method 
acquire of thread.lock object at remote 0x33d2fd0, _Condition__waiters=[], 
release=built-in method release of thread.lock object at remote 0x33d2fd0) at 
remote

[issue13992] Segfault in PyTrash_destroy_chain

2012-02-11 Thread Aaron Staley


Aaron Staley usaa...@gmail.com added the comment:

For some more context:

Python 2.7.2
Running on Amazon EC2
Linux 3.0.0-14-virtual x86_64 in ubuntu 11.10
170 threads in this particular core dump (another similar crash has 135)

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13992
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13666] datetime documentation typos


Aaron Maenpaa aa...@maenpaa.ca added the comment:

This patch fixes the rzinfo typo as well as the GMT2 issue (GMT +2 should 
behave exactly the same as GMT +1 with regards to DST, it's base offset should 
simply be +2 hours instead of +1).

This does not; however, address the comment about the first line of the 
tzinfo.utcoffset(). The fact that tzinfo.utcoffset() should return a timedelta 
or None is addressed later in the same paragraph, as such I'm not sure the 
proposed change is an improvement.

--
keywords: +patch
nosy: +zacherates
Added file: http://bugs.python.org/file24161/issue13666.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13666
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13666] datetime documentation typos


Aaron Maenpaa aa...@maenpaa.ca added the comment:

Looks like the issue of the first line of utcoffsect was also raised in issue 
8810.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13666
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12005] modulo result of Decimal differs from float/int


Aaron Maenpaa aa...@maenpaa.ca added the comment:

Here is a patch that adds an explination for the difference in the behaviour to 
the FAQ section of the Decimal documentation.

--
keywords: +patch
nosy: +zacherates
Added file: http://bugs.python.org/file24162/issue12005.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12005
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13730] Grammar mistake in Decimal documentation


New submission from Aaron Maenpaa aa...@maenpaa.ca:

In the sentance: In contrast, numbers like 1.1 and 2.2 do not have an exact 
representations in binary floating point. there is a mismatch in number 
between an and representations. I suggest removing an to make the whole 
thing plural.

A patch is attached.

--
assignee: docs@python
components: Documentation
files: plural.diff
keywords: patch
messages: 150813
nosy: docs@python, zacherates
priority: normal
severity: normal
status: open
title: Grammar mistake in Decimal documentation
versions: Python 3.3
Added file: http://bugs.python.org/file24164/plural.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13730
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13731] Awkward phrasing in Decimal documentation


New submission from Aaron Maenpaa aa...@maenpaa.ca:

The paragraph: The exactness carries over into arithmetic. In decimal floating 
point, 0.1 + 0.1 + 0.1 - 0.3 is exactly equal to zero. In binary floating 
point, the result is 5.5511151231257827e-017. While near to zero, the 
differences prevent reliable equality testing and differences can accumulate. 
For this reason, decimal is preferred in accounting applications which have 
strict equality invariants.

... has some awkward phrasing to my ear. I've attached a patch with a proposed 
alternative.

--
assignee: docs@python
components: Documentation
files: rephrase.diff
keywords: patch
messages: 150814
nosy: docs@python, zacherates
priority: normal
severity: normal
status: open
title: Awkward phrasing in Decimal documentation
versions: Python 3.3
Added file: http://bugs.python.org/file24165/rephrase.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13731
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13587] Correcting the typos error in Doc/howto/urllib2.rst


Aaron Maenpaa aa...@maenpaa.ca added the comment:

Here's a patch that makes the WWW-Authenticate headers in howto/urllib2 agree 
with rfc2617.

--
keywords: +patch
nosy: +zacherates
Added file: http://bugs.python.org/file24166/issue13587.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13587
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13731] Awkward phrasing in Decimal documentation


Aaron Maenpaa aa...@maenpaa.ca added the comment:

That's fine. I'm not particularly attached to that phrasing.

The one thing I would push for is to add a comma to ... decimal is preferred 
in accounting applications which have strict equality invariants.

... since, as far as I can tell, which have strict equality invariants is 
supposed to be a parenthetical statement explaining why accounting applications 
prefer to use decimal arithmetic, rather than a constraints on the preference 
for decimal arithmetic to only those accounting applications that have strict 
equality invariants.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13731
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13050] RLock support the context manager protocol but this is not documented


Aaron Maenpaa aa...@maenpaa.ca added the comment:

Here is a patch that adds an note about using Locks, RLocks, Conditions, and 
Semaphores as context managers to each of their descriptions as well as a link 
to the Using locks, conditions, and semaphores in the with statement section.

--
keywords: +patch
nosy: +zacherates
versions: +Python 3.3
Added file: http://bugs.python.org/file24167/issue13050.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13050
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13731] Awkward phrasing in Decimal documentation