-
Notifications
You must be signed in to change notification settings - Fork 93
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
Occasional race condition during compilation #282
Comments
Hi @rvalek , |
Hi @rvalek ,
It does look like there might be some kind of race condition in the way |
PS: It should also be easy to manually patch in the change into your fork if needed: 7164c91 |
Hey @EvgSkv! Thank you for looking into it! We applied your suggested change to try it out. I'll let you know whether the error is gone by the end of the week (it was occurring pretty infrequently, 5-10 times a week). |
@EvgSkv sorry to report that the errors are still happening. We noticed a few within an hour of applying your change |
Hi @rvalek Can you please try patching that and let me know if it helps? Apologies for the bug, I am sure it won't take too many iterations to have it eliminated. |
Hey @EvgSkv! |
Great to hear that @KantorSerhiy ! 😄 |
thanks again for helping out, @EvgSkv ! closing the issue |
Hi @EvgSkv!
Problem statement:
I am noticing a rather infrequent crash during compilation:
(the line numbers might be a bit shifted because I caught this on a slightly outdated compiler version -- this shouldn't relevant here).
This is coming from inside the builtin
copy.deepcopy
, and indicates that the number of keys of the dict inself.bulk_functions
was modified while it was being copied.I am getting this in a python process that may concurrently run several compilation (
LogicaProgram(parsed_logica, user_flags=flags).FormattedPredicateSql(...)
) threads.So, the guess is that one thread crashes during
copy.deepcopy
while another is somehow modified the same dict.Sentiment:
I know that compiler thread-safety is nowhere guaranteed, so I would totally understand if you chose to disregard issue.
That said, I chose to post here because I am a little dumbfounded: I see this error periodically happening on this threaded service, but I can't reproduce it directly. I am also out of ideas for now as to what causes it, because going through the code I reach the following conclusions:
self.bulk_functions
that is simultaneously being copied in another compilation in thread 1, then the thread 2 is at a stage of compilation that is before or after making it's owncopy.deepcopy
.bulk_functions
dict BEFORE making a deep copy must've already been done, inside the thread 1 compilation (because it has reachedcopy.deepcopy
and crashed), and looking at the code I see that oncebulk_functions
is populated (prior to copying), it will not be changed.So, I can't even put a finger or a specific place where thread 2 might be mutating
bulk_functions
during it's own compilation to cause a crash in thread 1's compilation atcopy.deepcopy
.What am I missing? Do you have an idea where I should be looking? Does the reasoning make sense? Is the whole direction wrong?
P.S.
While analysing the above, I was trying to understand the relevance of
CleanDictionary
, as I see it happens sometimes, but I never actually reach deletion of any keys when I try to go step-by-step with the debugger. Either way, it shouldn't be related to the above issue becauseCleanDictionary
operates on the deepcopy after it has been made, so it can't touch the original dict, right?Any ideas on this subject would be appreciated!
Sorry for a tl;dr...
The text was updated successfully, but these errors were encountered: