-
-
Notifications
You must be signed in to change notification settings - Fork 1.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
"Dumping very large path" message isn't helpful #1184
Comments
Yeah, a message in FdSink constructor seems the way to go. |
(well, actually, using constant space for dumping is obviously the way to go 😛 ) |
@domenkozar That patch doesn't apply cleanly without cf4a7ae. |
Having both would be really great :) |
@edolstra would you mind explaining what withholds these two commits back? These are two of the most annoying bugs I encounter when using Nix and even being experienced they are annoying to overcome. I think it's better to make it work&correct and we can correct the performance one day if needed. |
This is still an issue today. I just got that error message and don't know what path is causing the issue. |
I marked this as stale due to inactivity. → More info |
I think the prereq patch has landed on master in some form? This might also be straight up fixed on master too. |
Any chance it can be backported to the 2.3-maintenance branch used for making the 2.3.* releases https://github.com/NixOS/nix/blob/2.3-maintenance/src/libstore/local-store.cc ? The #2981 can be closed as it's forgotten and this different fix has been merged instead. |
I marked this as stale due to inactivity. → More info |
Fixes NixOS#1184 since it's now visible in the progress bar which path is taking a long time to copy.
This message was unhelpful (NixOS#1184) and probably misleading since memory is O(1) in most cases now.
This message was unhelpful (NixOS#1184) and probably misleading since memory is O(1) in most cases now.
this isn't stale, as the message is still shown and still not helpful |
This message was unhelpful (NixOS#1184) and probably misleading since memory is O(1) in most cases now.
It would be helpful to know which path is being dumped and ideally what led to the dumpage. Given where the warning is emitted right now in the code, it's not obvious to me how to add that detail to the message, but it's pretty unfriendly right now. I guess we could add a constructor parameter to an
FdSink
that tells it some human-meaningful representation of the thing being written to it?cc @edolstra @shlevy
The text was updated successfully, but these errors were encountered: