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
bundle:mem throws SystemStackError: stack level too deep #136
Comments
Hello @florianroesler Thanks for your issue. Do you think you can provide a way to reproduce this behavior? Cheers 👋 |
I tried some stuff again and it seems weirder than I thought. Actually, both versions (1.3.5 and 1.3.6) work sometimes but also fail sometimes with the above trace. So my initial suspicion was just based on pure luck that version 1.3.6 failed and 1.3.5 worked for the few runs I did. I will keep investigating and try to find a reproducible example! Have you seen similar behaviour before, where running the memory investigation would fail and succeed when executed multiple times? |
Sadly not. |
Can you give me a repro example that reproduces the behavior? |
Will do as soon as I find the time :) |
There you go: https://github.com/florianroesler/derailed_reproduction The README gives an action plan to reproduce the issue. I used Docker and docker-compose so that the execution environment should be the same for you. Let me know if you need further assistance. |
Thanks! I’m out for the weekend, will have a look soon though.
--
Richard Schneeman
https://www.schneems.com
|
I tried to repro with this setup but could not. I've got it running in a loop:
Tried on docker and on a mac. Can you try it out on another machine and see if you can get it to reproduce there? PerformanceI've not triggered the behavior yet. In a strange note, it runs MUCH faster on docker than on my mac
Not sure why, I thought it might be the number of gems installed, but they seem about the same:
Doesn't look like the issue is bundler version or rubygems version. Pretty bizarre. |
Ok, I was really clueless on why you had different results than me. Also checked with a coworker and freshly set up the project, he also couldn't reproduce the error. For the reproduction of the error I have now pinned the image version of ruby:2.5.1-alpine to that very digest that fails for me. Just check out the newest version of the reproduction repository and rebuild the image using |
Thanks for the container and repro. Is there a way to diff docker images? I don’t want to invest a ton of time here if the issue was a bug in the container instead of in the library. I.e. I’m not sure I would be able to do anything about it in derailed also this is the only case I’ve ever seen of this happening. |
Understandable, you shouldn't invest your time here. I am still wondering what underlying differences in the images could lead to a SystemStackError when executing derailed. I will close this issue. I guess if anyone else ever encounters a similar issue, we can pick this up again. Thank you very much for your assistance! |
Here's some investigation on why it's so slow on mac zombocom/get_process_mem#31 |
When using the recently released version 1.3.6 I get the following stacktrace upon executing
bundle exec derailed bundle:mem
:When installing 1.3.5, everything is fine again. I am running the command in an Alpine based Docker container with Rails 5.2. Let me know if I can support with additional information.
The text was updated successfully, but these errors were encountered: