[issue10181] get_shape0 in memoryobject.c not checked for error return

Nick Coghlan added the comment: Hmm, if we're ever creating a new copy of a Py_buffer without calling GetBuffer again on the original object, then *that* is a bug (exactly comparable to copying a PyObject pointer without incrementing the reference count - it's OK if you can guarantee the life

[issue10181] get_shape0 in memoryobject.c not checked for error return

Roger Upole added the comment: While on the subject, the docs for PyMemoryView_FromBuffer state that the resulting memoryview takes ownership of the Py_buffer struct and is responsible for freeing any associated memory. It does not do so, which is not surprising. The absence of a standard f

[issue10181] get_shape0 in memoryobject.c not checked for error return

Roger Upole added the comment: The culprit wrt copying Py_buffer structs seems mainly to be dup_buffer, which is called in memory_getbuf. This seems unnecessary in the case where there's an underlying object and it has returned the view thru its own tp_as_buffer. The underlying object at th

[issue10181] get_shape0 in memoryobject.c not checked for error return

Antoine Pitrou added the comment: > Read the "Releasing the buffer" section in PEP 3118 again. Unless I'm > misunderstanding you completely, the rules you're asking for are > already in place: those fields are entirely the responsibility of the > exporting object, and it needs to ensure they rem

[issue10181] get_shape0 in memoryobject.c not checked for error return

Nick Coghlan added the comment: Read the "Releasing the buffer" section in PEP 3118 again. Unless I'm misunderstanding you completely, the rules you're asking for are already in place: those fields are entirely the responsibility of the exporting object, and it needs to ensure they remain val

[issue10181] get_shape0 in memoryobject.c not checked for error return

Antoine Pitrou added the comment: > As far as I know, PEP 3118 serves its purpose of allowing extension > modules like numpy and PIL to share data without needing to copy it > around all the time. It's just that memoryview wasn't really part of > that purpose (since all the affected third party

[issue10181] get_shape0 in memoryobject.c not checked for error return

Nick Coghlan added the comment: As far as I know, PEP 3118 serves its purpose of allowing extension modules like numpy and PIL to share data without needing to copy it around all the time. It's just that memoryview wasn't really part of that purpose (since all the affected third party librari

[issue10181] get_shape0 in memoryobject.c not checked for error return

Antoine Pitrou added the comment: Yes, there are probably many holes like this. I've done what I could to make the simple cases (builtin types) to work, but the spec is rotten from the start. Blame the numpy people, sorry. -- nosy: +ncoghlan ___ Py

[issue10181] get_shape0 in memoryobject.c not checked for error return

Changes by Éric Araujo : -- nosy: +pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.or

[issue10181] get_shape0 in memoryobject.c not checked for error return

New submission from Roger Upole : There are a number of places in memoryobject.c where get_shape0 is used without the return value being checked. If it fails, this leads to hanging exceptions and crashes. -- components: Interpreter Core messages: 119460 nosy: rupole priority: normal s