[issue30749] Non-atomic and unusual (wrong) rename behavior under OS X
Alex Groce added the comment: Looks to be OS X rename, not Python -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30749> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30749] Non-atomic and unusual (wrong) rename behavior under OS X
Alex Groce added the comment:
#include
#include
#include
#include
int main () {
system("rm -rf testingdir");
mkdir("testingdir",S_IRWXU);
mkdir("testingdir/a",S_IRWXU);
mkdir("testingdir/a/a",S_IRWXU);
mkdir("testingdir/a/a/a",S_IRWXU);
printf("BEFORE:\n");
system("ls -lR testingdir");
int res = rename("testingdir","testingdir/a/a/a");
printf("res = %d, ERRNO = %d\n",res,errno);
printf("AFTER:\n");
system("ls -lR testingdir");
}
shows that it appears to be an OS X rename issue, not a Python problem.
Lowering # directories in the chain by 1 reverts to errno 22 and correct
behavior, but it's at the OS level, not Python.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30749>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30749] Non-atomic and unusual (wrong) rename behavior under OS X
Alex Groce added the comment: Tested on latest Mac OS; mv at command line does the right thing, have not checked a C rename yet. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30749> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30749] Non-atomic and unusual (wrong) rename behavior under OS X
Alex Groce added the comment: Checked, and this is a problem on Python 3 as well as 2.7. -- title: Non-atomic and unusual (wrong) rename behavior under OS X, Python 2.7.13 -> Non-atomic and unusual (wrong) rename behavior under OS X versions: -Python 2.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30749> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30749] Non-atomic and unusual (wrong) rename behavior under OS X, Python 2.7.13
New submission from Alex Groce: Attached file causes a failed rename, which is fine. However, after the failed rename, the directory structure has changed (and the error reported is not very helpful). Behavior does not match Linux or Windows behavior. Discovered using random testing to check pyfakefs for conformance with os module, using TSTL tool. -- components: macOS files: renameatomic.py messages: 296794 nosy: Alex Groce, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: Non-atomic and unusual (wrong) rename behavior under OS X, Python 2.7.13 type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file46973/renameatomic.py ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30749> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27870] Left shift of zero allocates memory
Alex Groce added the comment: I mean a Python long. GMP mpz (via gmpy2) is supposed to be "drop-in" replacement, but it's choice to handle 0 << N even if N is too large to allocate (since you get back a 1-bit number, 0) seems reasonable, if not required for correct behavior. If this is by design, it seems reasonable (if the zero check is considered too expensive, for example). -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue27870> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27870] Left shift of zero allocates memory
Alex Groce added the comment: Allocates, then fails to perform the operation (with MemoryError). Neither a crash nor resource allocation, precisely, just fails to carry out operation GMP integers can do under the same circumstances. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue27870> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27870] Left shift of zero allocates memory
Alex Groce added the comment: AND, right shift >> does not allocate memory, so there is a lack of symmetry that indicates the optimization might be desired. see https://github.com/agroce/tstl/tree/master/examples/gmpy2/leftshiftalloc.py vs. https://github.com/agroce/tstl/tree/master/examples/gmpy2/rightshiftalloc.py to compare behaviors, but these are depending on memory size, this was generated on MacBook Pro OS X Yosemite machine with 16GB) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue27870> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27870] Left shift of zero allocates memory
Alex Groce added the comment: (to clarify: 0 << N allocates memory (which can fail, raising MemoryError) based on N. GMP simply returns 0 for any N. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue27870> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27870] Left shift of zero allocates memory
New submission from Alex Groce: Using a random testing system to compare Python long behavior to GMP (via gmpy2), I notice that in a low-memory situation (created by allocating many large integers in both Python and GMP), a left-shift of 0 by large number of bytes: - returns 0 via gmpy2 - causes a memory error in Python, e.g.: ... val4 = val3 << val4 val3: 0 (GMP) 0 (Python) val4: 1459166279268040830 (GMP) 1459166279268040830 (Python) [operation successful via GMP] Python(4463,0x7fff7152c300) malloc: *** mach_vm_map(size=19403902408704) failed (error code=3) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug Auto-generated test is attached, though probably not needed to understand the issue. File is not minimized, since I suspect most of the code is just to choke memory, and you probably need the right memory config to replay, but it shows the basic idea. For more info, see https://github.com/agroce/tstl/tree/master/examples/gmpy2 -- files: leftshiftalloc.py messages: 273717 nosy: Alex Groce priority: normal severity: normal status: open title: Left shift of zero allocates memory type: resource usage versions: Python 2.7 Added file: https://bugs.python.org/file44236/leftshiftalloc.py ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue27870> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
