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
It's odd because i've seen this from 2 diff sources in the #302 history but not sure either are legit.
Main source of issue seems to be that we're loading boat loads of data and one of 2 sys level calls trigger this:
socket re-connection of some sort to the FSP engine inside the trio streams apis
our ShmArray's usage of stdlib's SharedMemory causes it when attaching (not creating) to an existing buffer repeatedly (again something the fsp engine will do on task respawn-resyncs when a new history frame is loaded.
Minimize calling `.data._shmarray.attach_shm_array()` as much as is
possible to avoid the crash from #332. This is the suggested hack from
issue #359.
Resolves#359
Minimize calling `.data._shmarray.attach_shm_array()` as much as is
possible to avoid the crash from #332. This is the suggested hack from
issue #359.
Resolves#359
It's odd because i've seen this from 2 diff sources in the #302 history but not sure either are legit.
Main source of issue seems to be that we're loading boat loads of data and one of 2 sys level calls trigger this:
trio
streams apisShmArray
's usage of stdlib'sSharedMemory
causes it when attaching (not creating) to an existing buffer repeatedly (again something the fsp engine will do on task respawn-resyncs when a new history frame is loaded.The next time someone sees this please put in the whole traceback. I've stuck some preventative code in #302 but it didn't seem to do much for me iirc.
Another thing we cam try for the shm case is a busy loop around the non-create call:
and see if that triggers it, in which case it's likely a lower level bug we can report?
The text was updated successfully, but these errors were encountered: