Skip to content
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

Warnings since update version 0.7.0 #30

Closed
yvbeek opened this issue Mar 23, 2017 · 21 comments
Closed

Warnings since update version 0.7.0 #30

yvbeek opened this issue Mar 23, 2017 · 21 comments

Comments

@yvbeek
Copy link

yvbeek commented Mar 23, 2017

I am using Prawn and they switched to the new version of PDF-Core. But since the update I'm getting the following warnings on my production environment.

vendor/bundle/ruby/2.3.0/gems/pdf-core-0.7.0/lib/pdf/core/text.rb:12: warning: already initialized constant PDF::Core::Text::VALID_OPTIONS
vendor/bundle/ruby/2.3.0/gems/pdf-core-0.7.0/lib/pdf/core/text.rb:12: warning: previous definition of VALID_OPTIONS was here
vendor/bundle/ruby/2.3.0/gems/pdf-core-0.7.0/lib/pdf/core/text.rb:13: warning: already initialized constant PDF::Core::Text::MODES
vendor/bundle/ruby/2.3.0/gems/pdf-core-0.7.0/lib/pdf/core/text.rb:13: warning: previous definition of MODES was here

Do you guys have an idea what might be causing this?
I don't get the warnings on my development environment.

@pointlessone
Copy link
Member

Are those the only warnings you get?

@hovancik
Copy link

same here

/home/www/production/apps/xxx/releases/3/vendor/bundle/ruby/2.3.0/gems/pdf-core-0.7.0/lib/pdf/core/text.rb:12: warning: already initialized constant PDF::Core::Text::VALID_OPTIONS
/home/www/production/apps/xxx/shared/vendor/bundle/ruby/2.3.0/gems/pdf-core-0.7.0/lib/pdf/core/text.rb:12: warning: previous definition of VALID_OPTIONS was here
/home/www/production/apps/xxx/releases/3/vendor/bundle/ruby/2.3.0/gems/pdf-core-0.7.0/lib/pdf/core/text.rb:13: warning: already initialized constant PDF::Core::Text::MODES
/home/www/production/apps/xxx/shared/vendor/bundle/ruby/2.3.0/gems/pdf-core-0.7.0/lib/pdf/core/text.rb:13: warning: previous definition of MODES was here

@pointlessone
Copy link
Member

Could you please share your production server setup? What appserver do you use? What is your deployment strategy?

@hovancik
Copy link

hovancik commented Mar 23, 2017

Rails 5.0.2 on debian server.
2 things that could did it for me and happened recently (I mean yesterday when this started to happen):

  • I upgraded mina from 0.3 to 1.0
  • I upgraded rails from 5.0.1 to 5.0.2

@pointlessone
Copy link
Member

Do you use Unicorn, Puma or something else? What is the config for it? Do you use preloading? Etc.

@hovancik
Copy link

Puma here.

threads_count = ENV.fetch("RAILS_MAX_THREADS") { 5 }.to_i
threads threads_count, threads_count
workers ENV.fetch("WEB_CONCURRENCY") { 2 }
rails_env = ENV.fetch("RAILS_ENV") { "development" }
bind 'unix://tmp/sockets/puma.sock'
pidfile 'tmp/pids/puma.pid'
directory ENV.fetch("PUMA_DIR") { '.'}
stdout_redirect "log/puma.stdout.log", "log/puma.stderr.log", true
prune_bundler true

@yvbeek
Copy link
Author

yvbeek commented Mar 23, 2017

OS: Ubuntu 16.10 (GNU/Linux 4.8.0-41-generic x86_64)
Ruby: ruby 2.3.3p222 (2016-11-21 revision 56859) [x86_64-linux-gnu]
Rails: rails 4.2.8
Puma: puma 3.8.2

We deploy using Ansible. Our file structure is similar to that of Capistrano, with a releases folder and a symbolic link to the current release.

Puma configuration:

app_path = ENV['APP_PATH'] || File.expand_path('../../', __FILE__)

working_directory app_path
worker_processes 4
timeout 300

stdout_path "#{app_path}/log/server-app.log"
stderr_path "#{app_path}/log/server-app.log"

pid "#{app_path}/tmp/pids/server-app.pid"
listen "#{app_path}/tmp/sockets/server-app.sock"

# Preload the app, save memory by using copy-on-write
preload_app true

before_fork do |server, worker|
  # Prevent the master process from holding ActiveRecord connections
  defined?(ActiveRecord::Base) && ActiveRecord::Base.connection_handler.clear_all_connections!

  # This allows a new master process to incrementally phase out the old master process
  # with SIGTTOU when doing a transparent upgrade. The last worker spawned will then
  # kill off the old master process with a SIGQUIT.
  old_pid = "#{server.config[:pid]}.oldbin"
  if old_pid != server.pid
    begin
      signal = (worker.nr + 1) >= server.worker_processes ? :QUIT : :TTOU
      Process.kill(signal, File.read(old_pid).to_i)
    rescue Errno::ENOENT, Errno::ESRCH
    end
  end
end

@yvbeek
Copy link
Author

yvbeek commented Mar 23, 2017

I think I've found a clue to what is causing the warnings.

On the production platform the vendor/bundle folder is a symbolic link. If I move the bundle folder out of my vendor folder and replace it with a symbolic link I get the same warnings.

@pointlessone
Copy link
Member

There's a related issue: prawnpdf/prawn#1013.

The warning you're seeing is a result of $: having both the symlinked dir and the real one. This is not a problem but it may cause double load if you first require a file from one path, and than the same file from another path. Naturally, both files are the same and define the same constants. This is why you're getting the warnings.

The question is why the file is required twice and why it's done with different paths.

@yvbeek
Copy link
Author

yvbeek commented Mar 29, 2017

It seems that the following line in commit 54615e8 (lib/pdf/core.rb) is causing the warnings:

require_relative "core/text"

Should core/text be required there?

@yvbeek
Copy link
Author

yvbeek commented Apr 19, 2017

@pointlessone, @msbit is that require_relative necessary? It seems to be causing the issue.

@msbit
Copy link
Contributor

msbit commented Apr 20, 2017

@Zyphrax this was raised by @pointlessone during the PR review (#26), short story it was required for the spec to pass.

The other option is to require it in the spec proper (spec/text_spec.rb), which seems like the most feasible way to make prawn happy.

This issue could indicate a weird split for text between prawn and pdf-core; perhaps the spec belongs in prawn?

@dmke
Copy link

dmke commented Apr 21, 2017

This is reproducable with rbenv + rbenv-alias (which creates symlinks in ~/.rbenv/versions. Here, I have an alias ruby-2.3 pointing to the actual 2.3.3 installation:

~/.rbenv/versions/ruby-2.3/gemsets/xxx/gems/pdf-core-0.7.0/lib/pdf/core/text.rb:12: warning: already initialized constant PDF::Core::Text::VALID_OPTIONS
~/.rbenv/versions/2.3.3/gemsets/xxx/gems/pdf-core-0.7.0/lib/pdf/core/text.rb:12: warning: previous definition of VALID_OPTIONS was here
~/.rbenv/versions/ruby-2.3/gemsets/xxx/gems/pdf-core-0.7.0/lib/pdf/core/text.rb:13: warning: already initialized constant PDF::Core::Text::MODES
~/.rbenv/versions/2.3.3/gemsets/xxx/gems/pdf-core-0.7.0/lib/pdf/core/text.rb:13: warning: previous definition of MODES was here

This is especially annoying in development...

short story it was required for the spec to pass.

Sounds like the require_relative should move to the spec then, no?

@rrosenblum
Copy link

rrosenblum commented May 5, 2017

As mentioned by @pointlessone, this is the same issue as #1013. The issue is caused by using require_relative and mixing require styles when any of your path is in a symlink. This means that any application that is deployed using capistrano would be impacted. The correct way to fix this is to convert to using require in all of the prawn gems instead of using require_relative.

Requires are moved around. I'd rather keep them where they are now.

Unless you have a use for requiring a specific file/group of file from the gem independently, then there is no reason to have the requires at the top of each file. require 'prawn' will load everything that is needed.

This is not a Prawn issue but user's set up. Also the proposed fix introduces other issues.

This is a prawn issue. I do not believe that the proposed fix would introduce other issues. I do not consider using a symlink is a valid reason to justify this issue.

So as you can see, if you have two copies of Prawn (or any other gem) they both are going to be loaded.
Now, the new issue I mentioned is that with only require you can only load files from the gem that comes first in $:. So if you manage to load a file from the second instance, it will require files from the first one. This is potentially problematic when you have two different versions vendored.

I am not sure that this is correct. If it were, this would be a huge issue in bundler.

require does it by looking in every directory listed in $: (also known as $LOAD_PATH).
require_relative only differs in the way it looks for a file. It doesn't look in $:. It looks in the current directory

This is exactly why require_relative is bad to use here.

@pointlessone
Copy link
Member

I want to test a few ideas about this.

A short survey:

  • $LOAD_PATH
  • $LOADED_FEATURES
  • Do you use Bundler.setup?
  • Do you run your code from a symlinked directory?

@pointlessone
Copy link
Member

/cc @AnwarShah @shevegen

@pointlessone
Copy link
Member

This issue has been fixed upstream. The fix will be released in Ruby 2.5 and most probably won't be backported but this is still strong indication that this issue is manifestation of a bug. Since this is only warnings and maybe a minor performance issue during code loading I am strongly inclined to not address it in Prawn in any way.

Please give your feedback if you have other concerns that are not addressed by the Ruby fix.


This issue will be closed in a week.

@AnwarShah
Copy link

@pointlessone Sorry for not being able to reply to the previous question.
I output is from a normal irb session

  1. Output of p $LOAD_PATH
["/home/anwar/.rvm/gems/ruby-2.3.4@global/gems/did_you_mean-1.0.0/lib", "/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/site_ruby/2.3.0", "/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/site_ruby/2.3.0/x86_64-linux", "/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/site_ruby", "/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/vendor_ruby/2.3.0", "/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/vendor_ruby/2.3.0/x86_64-linux", "/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/vendor_ruby", "/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/2.3.0", "/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/2.3.0/x86_64-linux"]
  1. Output of puts $LOADED_FEATURES
enumerator.so
thread.rb
rational.so
complex.so
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/2.3.0/x86_64-linux/enc/encdb.so
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/2.3.0/x86_64-linux/enc/trans/transdb.so
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/2.3.0/unicode_normalize.rb
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/2.3.0/x86_64-linux/rbconfig.rb
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/site_ruby/2.3.0/rubygems/compatibility.rb
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/site_ruby/2.3.0/rubygems/defaults.rb
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/site_ruby/2.3.0/rubygems/deprecate.rb
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/site_ruby/2.3.0/rubygems/errors.rb
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/site_ruby/2.3.0/rubygems/version.rb
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/site_ruby/2.3.0/rubygems/requirement.rb
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/site_ruby/2.3.0/rubygems/platform.rb
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/site_ruby/2.3.0/rubygems/basic_specification.rb
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/site_ruby/2.3.0/rubygems/stub_specification.rb
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/site_ruby/2.3.0/rubygems/util/list.rb
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/2.3.0/x86_64-linux/stringio.so
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/site_ruby/2.3.0/rubygems/specification.rb
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/site_ruby/2.3.0/rubygems/exceptions.rb
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/site_ruby/2.3.0/rubygems/dependency.rb
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/site_ruby/2.3.0/rubygems/core_ext/kernel_gem.rb
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/2.3.0/monitor.rb
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/site_ruby/2.3.0/rubygems/core_ext/kernel_require.rb
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/site_ruby/2.3.0/rubygems.rb
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/site_ruby/2.3.0/rubygems/path_support.rb
/home/anwar/.rvm/gems/ruby-2.3.4@global/gems/did_you_mean-1.0.0/lib/did_you_mean/version.rb
/home/anwar/.rvm/gems/ruby-2.3.4@global/gems/did_you_mean-1.0.0/lib/did_you_mean/core_ext/name_error.rb
/home/anwar/.rvm/gems/ruby-2.3.4@global/gems/did_you_mean-1.0.0/lib/did_you_mean/levenshtein.rb
/home/anwar/.rvm/gems/ruby-2.3.4@global/gems/did_you_mean-1.0.0/lib/did_you_mean/jaro_winkler.rb
/home/anwar/.rvm/gems/ruby-2.3.4@global/gems/did_you_mean-1.0.0/lib/did_you_mean/spell_checkable.rb
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/2.3.0/delegate.rb
/home/anwar/.rvm/gems/ruby-2.3.4@global/gems/did_you_mean-1.0.0/lib/did_you_mean/spell_checkers/name_error_checkers/class_name_checker.rb
/home/anwar/.rvm/gems/ruby-2.3.4@global/gems/did_you_mean-1.0.0/lib/did_you_mean/spell_checkers/name_error_checkers/variable_name_checker.rb
/home/anwar/.rvm/gems/ruby-2.3.4@global/gems/did_you_mean-1.0.0/lib/did_you_mean/spell_checkers/name_error_checkers.rb
/home/anwar/.rvm/gems/ruby-2.3.4@global/gems/did_you_mean-1.0.0/lib/did_you_mean/spell_checkers/method_name_checker.rb
/home/anwar/.rvm/gems/ruby-2.3.4@global/gems/did_you_mean-1.0.0/lib/did_you_mean/spell_checkers/null_checker.rb
/home/anwar/.rvm/gems/ruby-2.3.4@global/gems/did_you_mean-1.0.0/lib/did_you_mean/formatter.rb
/home/anwar/.rvm/gems/ruby-2.3.4@global/gems/did_you_mean-1.0.0/lib/did_you_mean.rb
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/2.3.0/e2mmap.rb
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/2.3.0/irb/init.rb
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/2.3.0/irb/workspace.rb
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/2.3.0/irb/inspector.rb
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/2.3.0/irb/context.rb
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/2.3.0/irb/extend-command.rb
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/2.3.0/irb/output-method.rb
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/2.3.0/irb/notifier.rb
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/2.3.0/irb/slex.rb
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/2.3.0/irb/ruby-token.rb
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/2.3.0/irb/ruby-lex.rb
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/2.3.0/irb/src_encoding.rb
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/2.3.0/irb/magic-file.rb
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/2.3.0/x86_64-linux/readline.so
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/2.3.0/irb/input-method.rb
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/2.3.0/irb/locale.rb
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/2.3.0/irb.rb
/home/anwar/.rvm/rubies/ruby-2.3.4/lib/ruby/2.3.0/irb/completion.rb
/home/anwar/.rvm/scripts/irbrc.rb
  1. I don't know how to answer this. I use bundler to pull gems for the project

  2. Yes I use symlinked .rvm and it occurs only when I use symlinked rvm

@AnwarShah
Copy link

I think it would be better if this can be fixed in prawn if @msbit's new commit works. Not every one of will be able to use Ruby 2.5.

@pointlessone
Copy link
Member

Thank you everyone. I'll close this issue now. I'll take into consideration all the arguments once I have more time. Feel free to reopen if you have any arguments you believe may contribute to the discussion.

@pointlessone
Copy link
Member

You're invited to participate in the further discussion: prawnpdf/prawn#1181.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

7 participants