Ross Lagerwall added the comment:
Well the app has an infinite recursion.
This shows on Fedora Linux 17:
"""
Request Method: GET
Request URL:http://127.0.0.1:8000/
Django Version: 1.4
Exception Type: RuntimeError
Exception Value:
maximum
Ross Lagerwall added the comment:
Sorry, I didn't mean that it's impossible; I meant that it shouldn't happen and
it should be fixed :-)
Unfortunately I don't have access to an OS X box to test.
--
___
Python tracker
<
New submission from Ross Lagerwall:
results for fa745ed89b7a on branch "default"
test_capi leaked [2, 2, 2] references, sum=6
Command line was: ['./python', '-m', 'test.regrtest', '-uall', '
Changes by Ross Lagerwall :
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Ross Lagerwall added the comment:
It's caused by the following check in _posixsubprocess.c:
if (close_fds && errpipe_write < 3) { /* precondition */
PyErr_SetString(PyExc_ValueError, "errpipe_write must be >= 3");
return NULL;
}
which was w
Ross Lagerwall added the comment:
The attached patch + test seems to fix the issue.
It's not very elegant.
--
keywords: +patch
Added file: http://bugs.python.org/file27042/issue15798.patch
___
Python tracker
<http://bugs.python.org/is
Ross Lagerwall added the comment:
I sent a review through on rietveld; I'm attaching a patch with the changes so
that it compiles and passes the tests.
--
Added file: http://bugs.python.org/file27053/issue15798_v2.patch
___
Python tracker
New submission from Ross Lagerwall:
[1/1] test_curses
beginning 6 repetitions
123456
.
test_curses leaked [1, 1, 1] references, sum=3
1 test failed:
test_curses
[154814 refs]
--
assignee: rosslagerwall
messages: 169973
nosy: rosslagerwall
priority: low
severity: normal
status: open
Ross Lagerwall added the comment:
This didn't get picked up by Antoine's daily refleak test run because test
curses only runs when stdout is a TTY.
--
___
Python tracker
<http://bugs.python.o
Changes by Ross Lagerwall :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Ross Lagerwall :
--
nosy: +rosslagerwall
___
Python tracker
<http://bugs.python.org/issue16140>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ross Lagerwall :
--
assignee: -> rosslagerwall
nosy: +rosslagerwall
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
versions: +Python 3.2, Python 3.4
___
Python tracker
<http://bugs.python
Changes by Ross Lagerwall :
--
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue16639>
___
___
Python-bugs-
Ross Lagerwall added the comment:
It seems like getgrouplist returns the information from the system
database whereas getgroups (and consequently id -G) returns the
supplementary groups for the calling process.
I'm not exactly sure how getgrouplist() can be effectively tested
Ross Lagerwall added the comment:
I wouldn't think so. A call to setgroups can add or remove groups for
the calling process. If it removes groups, then getgrouplist() won't
return a subset of getgroups().
--
___
Python trac
Ross Lagerwall added the comment:
Is that fixed now? I simplified the test to check for a non-empty list being
returned.
--
___
Python tracker
<http://bugs.python.org/issue16
Changes by Ross Lagerwall :
--
assignee: -> rosslagerwall
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python
Ross Lagerwall added the comment:
getgrouplist() is new in 3.3. Those failures are from getgroups() failing. I'll
open a separate issue for that.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org
New submission from Ross Lagerwall:
test_posix.test_getgroups() fails on some systems:
http://buildbot.python.org/all/builders/AMD64%20Mountain%20Lion%20%5BSB%5D%203.2
This could be related to #16661.
--
components: Tests
messages: 177601
nosy: rosslagerwall
priority: normal
severity
Changes by Ross Lagerwall :
--
nosy: +rosslagerwall
___
Python tracker
<http://bugs.python.org/issue16850>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ross Lagerwall :
--
nosy: +rosslagerwall
___
Python tracker
<http://bugs.python.org/issue16853>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ross Lagerwall added the comment:
Interesting benchmark. There is no gain for epoll with a large number of
ready fds (as expected) but at least it is no worse than poll. Poll offers
a large improvement on select, in this case.
$ ./python selector_bench.py -r 2 -m 1000 -t pipe
Trying with 2
Ross Lagerwall added the comment:
> Ross, the select() result for a large number of ready FDs was
> completely skewed because of a bug spotted by Antoine (complexity
> was much worse than it ought to be).
Ah, that makes a little more
Ross Lagerwall added the comment:
Hi,
There shouldn't be a problem with the existing implementation since, according
to posix:
"""
The pointer returned by readdir() points to data which may be overwritten by
another call to readdir() on the same directory stream. This data
Ross Lagerwall added the comment:
That text was from the POSIX 2008 spec:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/readdir.html
The following text from my copy of the readdir manpage gives an indication of
how you *should* allocate struct dirent when using readdir_r:
"&qu
Changes by Ross Lagerwall :
--
nosy: +rosslagerwall
___
Python tracker
<http://bugs.python.org/issue17552>
___
___
Python-bugs-list mailing list
Unsubscribe:
301 - 326 of 326 matches
Mail list logo
