This is the third time I've seen a crash on 2 different machines.
This is the first time I noticed this unexplained crash:
http://python.org/dev/buildbot/all/amd64%20gentoo%20trunk/builds/1983/step-test/0
That was at r54982.
I tried to reproduce this: with a non-debug build, with a debug build,
In rev 54982 (the first time this crash was seen), I see something
which might create a problem. In python/trunk/Modules/posixmodule.c
(near line 6300):
+ PyMem_FREE(mode);
Py_END_ALLOW_THREADS
Can you call PyMem_FREE() without the GIL held? I couldn't find it
documented either
On 5/1/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
After doing some research I found that it seems to be impossible to
use CreateFile for a file that doesn't have SHARE_READ. I played with
different combinations and with FLAG_BACKUP_SEMANTICS and nothing
helped. However on Windows there's
Raghuram Devarakonda wrote:
As a last resort, I
checked cygwin documentation which claims that it's rename() is
POSIX.1 compliant. If I am not mistaken, POSIX.1 does require
atomicity so I am curious how rename() is implemented there.
The cygwin implementation of rename goes like this:
1)
Alexey Borzenkov schrieb:
On 5/1/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
After doing some research I found that it seems to be impossible to
use CreateFile for a file that doesn't have SHARE_READ.
So what about GetFileAttributesEx? What are the conditions under which
I can successfully
Brett's PEP 3122 prompted me to finally PEP'ify my proposed solution for
the current incompatibility between PEP 328 (absolute imports) and PEP
338 (executing modules as scripts).
The only user visible change (other than bug 1510172 going away) would
be the presence of a new module level
On 5/1/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
That code only tests it for pagefile.sys. My question was about open
handles in general. Both Calvin Spealman and I found that you cannot
reproduce the problem when you, in Python 2.5.0, open a file, and then
try to os.stat() it - even
Hm, I fail to see the importance of a special regression test for that
peculiar file then with its special magical OS properties. Why not focus
our attention on real, user generated files?.
-Original Message-
Wow, I'm very sorry, I didn't realize how much special pagefile.sys
and
Kristján Valur Jónsson schrieb:
Hm, I fail to see the importance of a special regression test for that
peculiar file then with its special magical OS properties. Why not focus
our attention on real, user generated files?.
Because real users really had real problems with this very real file,
On 5/1/07, Scott Dial [EMAIL PROTECTED] wrote:
The cygwin implementation of rename goes like this:
1) Try to use MoveFile
2) Try to use MoveFileEx(..., MOVEFILE_REPLACE_EXISTING)
3) Try to unlink destination, then try to use MoveFile
And as you say, Cygwin claims it meets POSIX.1. And,
On 5/1/07, Kristján Valur Jónsson [EMAIL PROTECTED] wrote:
Hm, I fail to see the importance of a special regression test for that
peculiar file then with its special magical OS properties. Why not focus
our attention on real, user generated files?.
(Try to stick to the posting conventions and
Would tests that use ctypes do do the open directly be acceptable ways
of solving this?
If it solves it - sure.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On 27 Apr, 2007, at 20:39, Facundo Batista wrote:
- and (and), or (or), xor (xor) [CD]: Takes two logical operands, the
result is the logical operation applied between each digit.
and and or are keywords, you can't have methods with those names:
def and(l, r): pass
File stdin, line 1
There seems to be an issue with the PEP index:
http://python.org/dev/peps/ lists PEP 3122 as the last PEP (not
counting PEP 3141 which is deliberately out of sequence). As a
work-around, an up to date index is here:
http://python.org/dev/peps/pep-/
PEPs 3123-3128 are alive and well and
Ronald Oussoren [EMAIL PROTECTED] wrote:
On 27 Apr, 2007, at 20:39, Facundo Batista wrote:
- and (and), or (or), xor (xor) [CD]: Takes two logical operands, the
result is the logical operation applied between each digit.
and and or are keywords, you can't have methods with those names:
On 5/1/07, Neal Norwitz [EMAIL PROTECTED] wrote:
In rev 54982 (the first time this crash was seen), I see something
which might create a problem. In python/trunk/Modules/posixmodule.c
(near line 6300):
+ PyMem_FREE(mode);
Py_END_ALLOW_THREADS
The PyMem_MALLOC call that
I believe the GIL does not need to be held, but obviously Tim or someone
with more memory experience should step in to say definitively.
If you look at Include/pymem.h, PyMem_FREE gets defined as PyObject_FREE
in a debug build. PyObject_Free is defined at _PyObject_DebugFree.
That
Neal Norwitz nnorwitz at gmail.com writes:
Can you call PyMem_FREE() without the GIL held? I couldn't find it
documented either way.
Nope. See comments at the top of Python/pystate.c.
Cheers,
mwh
___
Python-Dev mailing list
but I got to a different conclusion. If it really goes through the
pymalloc pool (obmalloc), then it must hold the GIL while doing so.
obmalloc itself is not thread-safe, and relies on the GIL for
thread-safety.
In release mode, PyMEM_FREE goes directly to free, which is thread-
safe.
Yes.
Ronald Oussoren wrote:
- and (and), or (or), xor (xor) [CD]: Takes two logical operands, the
result is the logical operation applied between each digit.
and and or are keywords, you can't have methods with those names:
You're right. I'll name them logical_and, logical_or, and logical_xor.
Nick Maclaren wrote:
Am I losing my marbles, or is this a proposal to add the logical
operations to FLOATING-POINT?
Sort of. This is a proposal to keep compliant with the General Decimal
Arithmetic Specification, as we promised.
http://www2.hursley.ibm.com/decimal/
Regards,
--
.
Facundo Batista [EMAIL PROTECTED] wrote:
Am I losing my marbles, or is this a proposal to add the logical
operations to FLOATING-POINT?
Sort of. This is a proposal to keep compliant with the General Decimal
Arithmetic Specification, as we promised.
Kristján I'd suggest to keep the debug functions as a thin layer on top
Kristján of malloc to do basic testing.
But then you would substantially change the memory access behavior of the
program in a debug build, that is, more than it is already changed by the
fact that you have changed
[Neal Norwitz]
In rev 54982 (the first time this crash was seen), I see something
which might create a problem. In python/trunk/Modules/posixmodule.c
(near line 6300):
+ PyMem_FREE(mode);
Py_END_ALLOW_THREADS
Shouldn't do that.
[Brett Cannon]
The PyMem_MALLOC call that
On 5/1/07, Tim Peters [EMAIL PROTECTED] wrote:
[Neal Norwitz]
In rev 54982 (the first time this crash was seen), I see something
which might create a problem. In python/trunk/Modules/posixmodule.c
(near line 6300):
+ PyMem_FREE(mode);
Py_END_ALLOW_THREADS
Shouldn't do that.
On 4/29/07, Calvin Spealman [EMAIL PROTECTED] wrote:
Draft Attempt Number Duo:
PEP: XXX
Title: New Super
Checked in as PEP 3133.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
Georg Brandl has just checked this PEP in as 367. I had submitted it
to the [EMAIL PROTECTED] address, per the policy documentation. Sorry if
I subverted some policy order, or was non-vocal about it. I didn't
realize anyone else would check it in.
On 5/1/07, Guido van Rossum [EMAIL PROTECTED]
Totally my screwup. I'll discard 3133.
On 5/1/07, Calvin Spealman [EMAIL PROTECTED] wrote:
Georg Brandl has just checked this PEP in as 367. I had submitted it
to the [EMAIL PROTECTED] address, per the policy documentation. Sorry if
I subverted some policy order, or was non-vocal about it. I
28 matches
Mail list logo
