-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cloneEnv intermittently tries to relink a deleted effect #243
Comments
Hmm, this is very weird. Can you try with https://github.com/haskell-effectful/effectful/tree/hascallstack-runners? This should at least give you a location which deleted effect it tries to use. |
Great, that's helpful. I'll try and do it but it might be a bit since it only happens in production (:see_no_evil: ). In case it helps, here are a few possibly relevant facts:
So conceivably something is going wrong with cloning? Anyway, I'll try and run with your branch and report back. |
Ugh, my condolences. Ok, if this is a concurrent code and is hard to reproduce, that explains it. It looks like you have two threads using import Control.Concurrent
import Control.Concurrent.Async
import Effectful
import Effectful.Reader.Static
import Effectful.Dispatch.Static.Unsafe
works :: IO ()
works = runEff $ do
x <- runReader () $ do
withEffToIO (ConcUnlift Ephemeral $ Limited 1) $ \unlift -> do
x <- liftIO . async $ do
threadDelay 1000000
unlift ask
threadDelay 500000
pure x
liftIO $ wait x
fails :: IO ()
fails = runEff $ do
x <- runReader () $ do
reallyUnsafeUnliftIO $ \unlift -> do
x <- liftIO . async $ do
threadDelay 1000000
unlift ask
threadDelay 500000
pure x
liftIO $ wait x
Very unfortunate. It's likely you use a static effect that wraps an IO-based concurrent API and one of the wrapper functions has a bug, i.e. doesn't properly clone |
Ok, I merged #244 with a bunch of I also pushed https://github.com/haskell-effectful/effectful/tree/thread-sanitizer with a PoC of a primitive thread sanitizer. master:
thread-sanitizer:
Basically, whenever you access a fresh |
Hmmmmm. I don't think we're doing anything weird here. The two threads run together and the main thread waits for both, and I don't think anything changes the environment. But I think it must be something like that. That thread sanitizer stuff looks amazing! I will try that out too! |
The thread sanitizer did not trigger. Here's a stack trace:
So possibly a bug or gotcha in |
Well, that's one good news at least.
Well, it turns out that stack traces that come from However, I previously misread the trace. The code doesn't try to access the effect data, it tries to access its relinker. So looks like this is triggered inside I'm going to merge #247 that will start producing expected call stacks when undefined relinker is called, hopefully this sheds more light on the situation. |
Okay, I'll try running with #247 too. |
New day, new stack trace!
|
So we call an unlifting function, but when we copy our environment, some of it is missing? |
I am also somewhat baffled to say that switching |
Yeah, basically. It would be interesting if this indeed disappeared with switching to I fixed a bug in I don't think I can do much more without a reproducer and no access to your code :( Now that you have a location of the FWIW, I also pushed d97c9db so that when an undefined relinker is called, it will show both call stacks of its creation and its call site (since both are important), thought we already got them. |
Hmm okay. I will see if I can make a reproducer. Another question is: are there any functions exposed from |
Apart from stuff in Of course you can always just pass an Env to a different thread such that there is more than one thread operating on the same Env simultaneously, but then presumably you would've got errors from the thread-sanitizer branch. Btw, did you stop getting this error with |
Yes I did. Although to be honest, that may just mean that I've peturbed the situation enough that we happen not to trip over the problem, not that it's necessarily related. I'm planning to roll back that change occasionally to keep debugging 😅 |
undefined data
on effectful master
We've been running with
master
for a bit in order to get the fix for #237. I think we may have hit another bug?I don't have a reproducer, but we're getting the following error:
From a very cursory look, I guess this could occur if some parts of the environment are not initialized properly, which could conceivably have been introduced with the recent fix PRs? I can try and debug more, but it's not easy to reproduce. Perhaps a good step would just to be to add some more
HasCallStack
s?The text was updated successfully, but these errors were encountered: