[issue32533] SSLSocket read/write thread-unsafety
Alfred Krohmer <dev...@devkid.net> added the comment: Is there anything on the roadmap to fix this? This is a pretty severe bug given that this breaks multi-threaded OpenSSL while the documentation says it's thread-safe. -- nosy: +devkid ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32533> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33091] ssl.SSLError: Invalid error code (_ssl.c:2217)
New submission from Alfred Krohmer <dev...@devkid.net>: OpenSSL version: 1.1.0.g-1 OS: Arch Linux I'm creating an SSL socket like this: s = socket.create_connection((self.host, 443), 60) c = ssl.create_default_context() c.set_alpn_protocols(['spdy/2']) self.ss = c.wrap_socket(s, server_hostname=self.host) I'm then reading from the socket in one thread and writing to it in another thread. I'm experiencing strange behaviour. Sometimes I randomly get the error message in the title when invoking self.ss.recv(). After investigating the exception, I found that exc.errno = 10, which, according to the OpenSSL documentation means SSL_ERROR_WANT_ASYNC_JOB. This constant is never used in the _ssl.c file in cpython. This seems to me like an OpenSSL error that needs to be handled in the Python implementation but is not. Also sometimes I have random write timeouts when invoking self.ss.send() (in those cases it seems unlikely to me that those are caused by the server). Also I found here: https://github.com/python/cpython/blob/v3.6.4/Modules/_ssl.c#L2184 that Python uses SSL_get_error in an non-mutex locked section. But the OpenSSL documentation of SSL_get_error states the following: In addition to ssl and ret, SSL_get_error() inspects the current thread's OpenSSL error queue. Thus, SSL_get_error() must be used in the same thread that performed the TLS/SSL I/O operation, and no other OpenSSL function calls should appear in between. The current thread's error queue must be empty before the TLS/SSL I/O operation is attempted, or SSL_get_error() will not work reliably. According to that, shouldn't the _PySSL_UPDATE_ERRNO_IF macro be called *after* PySSL_END_ALLOW_THREADS? -- assignee: christian.heimes components: SSL messages: 313973 nosy: christian.heimes, devkid priority: normal severity: normal status: open title: ssl.SSLError: Invalid error code (_ssl.c:2217) type: behavior versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33091> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23276] hackcheck is broken in association with __setattr__
Alfred Krohmer added the comment: Can you elaborate what QtClass and QtMeta is in your case? My original example was reduced to a minimal case and seems to work with your suggestions. The complete example involving SQLalchemy is here: http://stackoverflow.com/questions/28032928/sqlalchemy-multiple-base-classes-not-working and does, however, not work. If I try to do # ... def __setattr__(cls, key, value): super(type(QMediaPlaylist), cls).__setattr__(cls, key, value) return The program segfaults when instantiating the Playlist class. However, this approach seems a little bit strange to me anyhow. The same happens when I try to do: # ... def __setattr__(cls, key, value): super(type(base), cls).__setattr__(cls, key, value) return I think that comes from PyQt specific attributes SQLalchemy is trying to set / replace. So, coming back to the original question, how can I actually set an attribute of my class Playlist from within its metaclass without involving the parent classes of the subclass (type(base) and type(QMediaPlaylist))? Because the __setattr__ from PyQt won't work (segfault) and the one from SQLalchemy does stupid stuff. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23276 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23276] hackcheck is broken in association with __setattr__
Alfred Krohmer added the comment: I'd expect a TypeError because of the extra cls argument. It's already a bound method. Sorry, that was a typo. Consider making a playlist class that *has* a SQL table, not one that *is* a SQL table, i.e. use composition instead of inheritance. That sidesteps the incompatible metaclasses. That would be indeed a solution, but not for the original problem. I think I have an example now that makes my point clear. The following code works as it should: import traceback import sys class MyMeta(type): def __setattr__(cls, key, value): print(OK) class MyClass(metaclass=MyMeta): pass MyClass.abc = 12 # outputs OK try: print(MyClass.abc) except: traceback.print_exc(file=sys.stdout) # exception comes here as expected type.__setattr__(MyClass, 'test', 42) # outputs nothing print(MyClass.test) # outputs 42 If I get this right, this should be **valid code** (and it should **not** be a bug, that this actually works). However, above define MyMeta like following: from PyQt5.QtMultimedia import QMediaPlaylist class MyMeta(type(QMediaPlaylist)): def __setattr__(cls, key, value): print(OK) And you get: TypeError: can't apply this __setattr__ to PyQt5.QtCore.pyqtWrapperType object I think that this actually **is** unexpected behaviour. I'm **not** trying to apply __setattr__ to PyQt5.QtCore.pyqtWrapperType but to MyClass! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23276 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23276] hackcheck is broken in association with __setattr__
New submission from Alfred Krohmer: The following code: import traceback import sys from PyQt5.QtCore import Qt class MetaA(type): pass class A(metaclass=MetaA): pass class MetaB(type): pass class B(metaclass=MetaB): pass for ClassB in B, Qt: print(Trying class %s % (ClassB.__name__, )) class MyMeta(type(A), type(ClassB)): def __setattr__(cls, key, value): print(cls) super(type, cls).__setattr__(key, value) class MyClass(A, ClassB, metaclass=MyMeta): pass try: setattr(MyClass, 'abc', 123) except: traceback.print_exc(file=sys.stdout) try: type.__setattr__(MyClass, 'test', 42) except: traceback.print_exc(file=sys.stdout) Fails with the following output: Trying class B class '__main__.MyClass' Traceback (most recent call last): File test3.py, line 31, in module setattr(MyClass, 'abc', 123) File test3.py, line 25, in __setattr__ super(type, cls).__setattr__(key, value) TypeError: can't apply this __setattr__ to type object Trying class Qt class '__main__.MyClass' Traceback (most recent call last): File test3.py, line 31, in module setattr(MyClass, 'abc', 123) File test3.py, line 25, in __setattr__ super(type, cls).__setattr__(key, value) TypeError: can't apply this __setattr__ to sip.wrappertype object Traceback (most recent call last): File test3.py, line 36, in module type.__setattr__(MyClass, 'test', 42) TypeError: can't apply this __setattr__ to sip.wrappertype object The metaclass of a class should be able to update its class' __dict__ my calling super(type, cls).__setattr__ (there is no other way known to me to do this). Furthermore, if subclassing an external class, like Qt, it should be possible to use type.__setattr__(MyClass, ...) externally to change the class' attributes. The error is caused by the hackcheck function in objects/typeobject.c. -- components: Interpreter Core, Library (Lib) messages: 234329 nosy: devkid priority: normal severity: normal status: open title: hackcheck is broken in association with __setattr__ type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23276 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
