-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
World age assertion precompiling modules #26278
Comments
I am running into the same issue with some random combination of precompiled modules and function definition. Can you still reproduce this on latest master? I can't check with my example due to #26665. |
Yes, this still reproduces, on 000f243 with updated packages as of today. |
Turns out this is not as easy to reproduce, and depends on the system I'm trying on. Maybe because of precompilation's nondeterminism (#25900)? Anyway, I'm trying to reduce the 50KSLOC that makes up DataFrames & deps to something sensible, I'll post that here when I have something that reproduces. |
OK, managed to reduce and reproduce: https://github.com/maleadt/26278 Check-out the repo, and execute
The code is ~100LOC, reduced from DataFrames.jl + deps by running |
OK, looks like this repro only needs a build with assertions enabled.
|
Fully reduced, ~50LOC now. Looks like the incremental deserializer isn't properly invalidating methods? |
Gets triggered somewhere else nowadays, but hasn't changed fundamentally:
|
Dude, for the 1,000,000 time, the triage label is not a lever to get people to look at bugs. |
The whole process of what goes on a milestone is unclear. It seemed like an important enough bug that I felt like marking triage so that triage could decide if it goes on the milestone. i.e. It does seem like a lever. If there are some well articulated rules for how this label works, I'll be happy to not piss everyone off. |
What goes on a milestone is changes that must be in a release because they are breaking, or otherwise release-defining. In contrast, bugs can be fixed any time and released in a point release like 1.0.x. |
It would seem that some bugs would be release stopping perhaps. But if the triage and milestone labels are strictly for features only, I can use them accordingly. |
Yes, a bug can be release-blocking if it's severe enough. In the past I believe we've been most interested in release-blocking bugs during the RC period, since fixing those is the main point of RCs. I think the thing to do in that case is clearly comment that you're marking a bug for triage because you believe it's release-blocking. The bar for that is pretty high though. |
Thanks for looking into this! |
EDIT: reduced example in #26278 (comment)
Set-up:
Repro:
Works in the REPL:
But hangs the compiler when executed (with DataFrames already precompiled) from a file, or with
--eval
:Running with assertions produces the following assertion failure:
Ref #23981 #24449
The text was updated successfully, but these errors were encountered: