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

Invalid Vagrantfile path and error line number reported, error reporting inconsistent #11022

Closed
ferenczy opened this issue Aug 14, 2019 · 3 comments · Fixed by #11056
Closed

Comments

@ferenczy
Copy link

Vagrant is reporting errors in Vagrantfile inconsistently and in some cases, the Vagrantfile path and the error line number are reported wrong.

Vagrant version

2.2.5 (64-bit)

Host operating system

Windows 7 Ultimate 64-bit

Vagrantfile

I have tested 4 different contents of the Vagrantfile. All of them contain an error of using an undefined variable or a syntax error, each time in a different scope, each time producing different (and in 2 cases wrong) Vagrantfile path and error line number report.

Case 1

vb.memory = "4096"

Case 2

Vagrant.configure("2") do |config|
  vb.memory = "4096"
end

Case 3

Vagrant.configure("2") do |config|
  config.vm.provider "virtualbox" do |vb|
      xvb.memory = "4096"
  end
end

Case 4

# test
abcd(

Expected behavior

Both the Vagrantfile path and the error line number are properly reported and ideally in the same format.

Actual behavior

Case 1

In this case, both the Vagrantfile path and the error line number are properly reported:

$ vagrant status
Vagrant failed to initialize at a very early stage:

There was an error loading a Vagrantfile. The file being loaded
and the error message are shown below. This is usually caused by
a syntax error.

Path: D:/work/memsource/vagrant/Vagrantfile
Line number: 1
Message: NameError: undefined local variable or method `vb' for main:Object

Case 2

In this case, the error line number is reported right, but Vagrantfile path is not:

$ vagrant status
Vagrant failed to initialize at a very early stage:

There was an error loading a Vagrantfile. The file being loaded
and the error message are shown below. This is usually caused by
an invalid or undefined variable.

Path: D
Line number: 2
Message: undefined local variable or method `vb'

Case 3

In this case, both the Vagrantfile path and the error line number seems to be wrong. The path looks like a code block specification where the error occurred and the error line number contains a broken Vagrantfile path (the proper path would be D:/work/memsource/vagrant/Vagrantfile as reported in the Case 1):

$ vagrant status
Vagrant failed to initialize at a very early stage:

There was an error loading a Vagrantfile. The file being loaded
and the error message are shown below. This is usually caused by
a syntax error.

Path: <provider config: virtualbox>
Line number: /work/memsource/vagrant/Vagrantfile
Message: NameError: undefined local variable or method `xvb' for main:Object

Case 4

This time, both Vagrantfile path and the error line number are right, but together with the error message, they're reported differently:

$ vagrant status
Vagrant failed to initialize at a very early stage:

There is a syntax error in the following Vagrantfile. The syntax error
message is reproduced below for convenience:

D:/work/memsource/vagrant/Vagrantfile:2: syntax error, unexpected end-of-input, expecting ')'

Steps to reproduce

  1. Create a Vagrantfile
  2. Run vagrant status in the same directory
@briancain
Copy link
Member

Hi @ferenczy - thanks for the detailed report!

I think case 2 is covered by #10924, but from the looks of it these cases can also be included in the fix since they are probably related/in the same area of code.

@briancain briancain added this to the 2.2.6 milestone Aug 15, 2019
@briancain briancain self-assigned this Aug 15, 2019
@ferenczy
Copy link
Author

OK, thank you for the information @briancain. Good to hear the fix is on its way :)

BTW similar issue (#6445) also has been reported and fixed about 4 years ago.

briancain added a commit to briancain/vagrant that referenced this issue Sep 6, 2019
…for windows

Prior to this commit, vagrant was not grabbing all of the tokens on
Windows for showing the full drive because the ruby api for it behaves
differenly on windows compared to other platforms. This commit changes
that by ensuring the letter drive is attached to the path when showing
an exception.
briancain added a commit to briancain/vagrant that referenced this issue Sep 6, 2019
…ions

Prior to this commit, if there was a config error inside a provider
block, Vagrant wouldn't grab the right backtrace token on windows since
the api is different for ruby on Windows compared to all other
platforms. This commit ensures that the proper line number is chosen so
the error message is correct.
briancain added a commit to briancain/vagrant that referenced this issue Sep 6, 2019
…ions

Prior to this commit, if there was a config error inside a provider
block, Vagrant wouldn't grab the right backtrace token on windows since
the api is different for ruby on Windows compared to all other
platforms. This commit ensures that the proper line number is chosen so
the error message is correct.
gitebra pushed a commit to gitebra/vagrant that referenced this issue Sep 13, 2019
* commit '9eac6ae62d6ad7acdd173fabe558ba75156245b6':
  Update CHANGELOG
  Update CHANGELOG
  Try to mock up docker version subprocess result in test
  Add vagrantfile mock to iso_env machine
  Add vagrantfile double for environment class
  Add allow for docker driver execute method
  Add machine config to machine double for rspec tests
  Remove virtualbox context from docker tests
  providers/docker: Fix usability check
  Remove platform require since it is no longer required in file
  Simplify line and path checks for exception handling in config loading
  Fixes hashicorp#11022: Ensure correct line is used for windows exceptions
  Fixes hashicorp#11022: Show proper path & letter drive on exceptions for windows
@ghost
Copy link

ghost commented Jan 28, 2020

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@ghost ghost locked and limited conversation to collaborators Jan 28, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants