Bug #4301

Off-by-one line number in Psych parse error

Added by Charles Nutter over 4 years ago. Updated almost 4 years ago.

[ruby-core:34690]
Status:Third Party's Issue
Priority:Normal
Assignee:Aaron Patterson
ruby -v:ruby 1.9.2p136 (2010-12-25 revision 30365) [x86_64-darwin10.6.0] Backport:

Description

=begin
For the following yaml:

# based on "SGML/XML character entity reference" at http://www.bitjungle.com/isoent/
#


#DOUBLE LOW-9 QUOTATION MARK
#requires fontenc:T1
ldquor: ,,

Psych produces the following error:

/Users/headius/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/1.9.1/psych.rb:148:in `parse': couldn't parse YAML at line 5 column 9 (Psych::SyntaxError)

The error is at line 6, not line 5.
=end

History

#1 Updated by Anonymous over 4 years ago

  • Status changed from Open to Closed
  • % Done changed from 0 to 100

=begin
This issue was solved with changeset r30628.
Charles, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.


  • ext/psych/parser.c (parse): fixing off-by-one error on line numbers in parse exceptions.
  • test/psych/test_parser.rb: test for error =end

#2 Updated by Charles Nutter over 4 years ago

=begin
Hmm, I think there's more to this, and it could certainly be a bug in libyaml. The following version has the correct line number, without your patch:

~ ➔ ruby -rpsych -ryaml -e 'YAML.parse("---\nldquor: ,,")'/Users/headius/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/1.9.1/psych.rb:148:in parse': couldn't parse YAML at line 1 column 9 (Psych::SyntaxError)
from /Users/headius/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/1.9.1/psych.rb:148:in
parse_stream'
from /Users/headius/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/1.9.1/psych.rb:119:in parse'
from -e:1:in
'

So there's something about the yaml I posted in the bug description that's special
=end

#3 Updated by Aaron Patterson over 4 years ago

=begin
On Sat, Jan 22, 2011 at 05:23:35PM +0900, Charles Nutter wrote:

Issue #4301 has been updated by Charles Nutter.

Hmm, I think there's more to this, and it could certainly be a bug in libyaml. The following version has the correct line number, without your patch:

~ ➔ ruby -rpsych -ryaml -e 'YAML.parse("---\nldquor: ,,")'/Users/headius/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/1.9.1/psych.rb:148:in parse': couldn't parse YAML at line 1 column 9 (Psych::SyntaxError)
from /Users/headius/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/1.9.1/psych.rb:148:in
parse_stream'
from /Users/headius/.rvm/rubies/ruby-1.9.2-p136/lib/ruby/1.9.1/psych.rb:119:in parse'
from -e:1:in
'

So there's something about the yaml I posted in the bug description that's special

You're right. I'm going to revert this patch and reopen the ticket
until I figure out what's wrong. This definitely looks like a libyaml
problem. :-(

--
Aaron Patterson
http://tenderlovemaking.com/

Attachment: (unnamed)
=end

#4 Updated by Aaron Patterson over 4 years ago

  • Status changed from Closed to Open
  • Assignee set to Aaron Patterson

=begin
Reopening as this seems like a bug in libyaml.
=end

#5 Updated by Charles Nutter over 4 years ago

=begin
FYI, 1.8/syck parses the yaml shown here, but libyaml (and SnakeYAML) do not (correctly). Ran into it because it's in a file that ships with RedCar:

https://redcar.lighthouseapp.com/projects/25090/tickets/464-redcar-ships-a-yaml-file-that-does-not-parse-with-libyaml-or-19s-wrapper-psych

Originally thought it was a bug in SnakeYAML:

http://code.google.com/p/snakeyaml/issues/detail?id=105&can=1

Just wanted to make it clear the yaml shown here does appear to be "correctly invalid".
=end

#6 Updated by Usaku NAKAMURA over 4 years ago

  • Status changed from Open to Assigned

=begin

=end

#7 Updated by Koichi Sasada almost 4 years ago

How about it?

#8 Updated by Hiroshi Nakamura almost 4 years ago

  • Target version set to 1.9.3

#9 Updated by Motohiro KOSAKI almost 4 years ago

  • Target version changed from 1.9.3 to 2.0.0
  • Category set to lib

I wonder why this issue is not 3rd party issue. Anyway this is not 1.9.3 material.

#10 Updated by Aaron Patterson almost 4 years ago

  • Status changed from Assigned to Third Party's Issue

Yes, this should be third party issue.

Also available in: Atom PDF