You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
And have it be wrapped by a decorator that will call the async_generator, run the deferred queries against a DB and .asend( the result back into the generator, which will throw an StopAsyncIteration at the conclusion of the generator, and allows me to catch it and end the generators execution.
I am getting my database access object library to run on Python 3.12 (jumping from Python 3.7).
However, on Python 3.12, a particular integration test that uses a particularly reduced implementation:
class Tenant:
@database(iterable=False, transaction=True)
async def invite_users(cls, *tenant_user_pairs, instance=None):
invites = (instance or cls).create_invites_for(*tenant_user_pairs)
gen_event_loop = Invite.save.raw_iterable(*invites)
result = None
while True:
result = await gen_event_loop.asend(result)
if isinstance(result, Return):
break
result = yield result
yield result # StopAsyncIteration gets thrown here
causes uvloop to crash with a Bus Error on OSX but only when loop.set_debug(True) (which is autoset via the environment variables or interpreter devmode)
Regular asyncio, debug or not, works just fine. If I patch the EventLoopPolicy to.set_debug(False) like:
def patch_uvloop():
if uvloop_version_info < (99, 99, 99) and platform.system() == 'Darwin':
cls = uvloop.EventLoopPolicy
if hasattr(cls, '__patched__'):
return cls
class EventLoopPolicy(cls):
__patched__ = True
# ARJ: so uvloop will crash the entire interpreter sometimes
# and the crash originates on OSX. Disable debug mode
# (which keeps it from touching uvloop's extract_stack() which
# explodes badly)
def _loop_factory(self):
loop = super()._loop_factory()
loop.set_debug(False)
return loop
uvloop.EventLoopPolicy = EventLoopPolicy
asyncio.set_event_loop_policy(uvloop.EventLoopPolicy())
Then the crashes never happen.
I do have lldb/gdb and the patience to recompile things with more debugging information (provided I know -how-) but a careful inspection of the following stack trace shows that it explodes after going into the extract_stack function of uvloop:
PYTHONASYNCIODEBUG
in env?:-X dev
orPYTHONDEVMODE=1
orPYTHONASYNCIODEBUG=1
orloop.set_debug(True)
loop.set_debug(False)
do not crash in nested async_generator.asend
callsI have a pattern called
DeferredExecutor
which basically allows one to write:And have it be wrapped by a decorator that will call the async_generator, run the deferred queries against a DB and
.asend(
the result back into the generator, which will throw anStopAsyncIteration
at the conclusion of the generator, and allows me to catch it and end the generators execution.I am getting my database access object library to run on Python 3.12 (jumping from Python 3.7).
However, on Python 3.12, a particular integration test that uses a particularly reduced implementation:
causes uvloop to crash with a Bus Error on OSX but only when
loop.set_debug(True)
(which is autoset via the environment variables or interpreter devmode)Regular asyncio, debug or not, works just fine. If I patch the EventLoopPolicy to
.set_debug(False)
like:Then the crashes never happen.
I do have lldb/gdb and the patience to recompile things with more debugging information (provided I know -how-) but a careful inspection of the following stack trace shows that it explodes after going into the
extract_stack
function of uvloop:uvloop/uvloop/handles/handle.pyx
Lines 118 to 119 in 6c770dc
uvloop/uvloop/cbhandles.pyx
Lines 14 to 15 in 6c770dc
This does remind me of python/cpython#94694
I wonder if the extract_stack function is tolerant of encountering negative numbers in the offset extraction of the trace.
Stack report:
stack.txt
The text was updated successfully, but these errors were encountered: