Replaced StringValuePtr to StringValueCStr

[ymmtmdk]

On ruby-head environment, I got the following error:

PG::CharacterNotInRepertoire: ERROR: invalid byte sequence for encoding "UTF8": 0xe0 0x0c 0xf7

I researched the code and found it may occured by not terminated C string.
In Ruby’s README.ext,

You can also use the macro named StringValueCStr(). This is just
like StringValuePtr(), but always add nul character at the end of
the result. If the result contains nul character, this macro causes
the ArgumentError exception.
StringValuePtr() doesn't guarantee the existence of a nul at the end
of the result, and the result may contain nul.

So, I made this patch and solved the error.
Is this right?

[larskanis]

Thank you for the bug report!

You're right in respect to StringValuePtr(), but we can not blindly replace all occurrences by StringValueCStr(), because we do handle binary data on several places as well.

Could you please post some code that triggered the error message for you? We need a test cast before we do any changes.

[ymmtmdk]

Thank you for you comment.
Agreeing, this patch is too blindly.
I can provide the code, but it is using Rails..
I challenged to reproduce the bug without Rails, but I unfortunately couldn't.

If you could read Rails, this is very simple scaffold App.
https://github.com/ymmtmdk/emailapp
Thank you.

[larskanis]

OK, I'll give it a try. Which OS are you using? And how did you install Ruby?

[ymmtmdk]

Thank you. I reproduced this in OS X and Amazon Linux. Both Ruby were Installed by "rvm install ruby-head". I updated the README.doc slightly. Please read it.

[larskanis]

Your rails project is working great, but unfortunately I'm not able to reproduce the error on Ubuntu-14.04 running on a fresh ruby version installed by rvm install ruby-head. Valgrind throws a lot of failures because of uninitialized variables, but none of them are related to this issue. I also couldn't find a single case in MRI's string.c, that creates a String object without 0-termination. So I currently don't have a good idea, how we could implement correct String usage without being able to test it.

[ymmtmdk]

Thank you for your try. I pushed a project to Github. I tried this on ubuntu14.04(and PostgreSQL9.3 and today's Ruby) in AWS, and this showed the error. Could you try this please?

https://github.com/ymmtmdk/sample_app_rails

[ymmtmdk]

might need to run "rake" twice.

[larskanis]

@ymmtmdk Now I get the same error raised on Ubuntu-14.04. I couldn't find out easily, which Ruby construct builds non zero terminated String objects, nor whether this behavior is really desired. But the README.ext is quite clear about zero termination, so I scanned my type cast branch for interesting cases and fixed it accordingly. I hope we can merge it soon, or we need to backport the commit elsewise.

[ymmtmdk]

I asked how to create not null terminated string at ruby-dev ML. Comitter naruse-san said, it can not be in Ruby but can do it in an extension. And he showed to me the code http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/48598

So, I have created a Gem https://github.com/ymmtmdk/not_null_terminated
Usage example:

require 'pg'
require 'not_null_terminated'

def nnt(sql)
  inst = "; INSERT INTO users (email) VALUES ('ymmt')"
  str = NotNullTerminatedString.new(sql+inst)
  inst.size.times{
    str.chop_without_terminate
  }
  str
end

slct = "SELECT * FROM users"
nnt_slct = nnt(slct)
p nnt_slct == slct #true
p nnt_slct =~ /INSERT/ #nil

conn = PG.connect( dbname: 'emailapp_test' )
conn.exec(nnt_slct)
conn.exec(slct){|result|
  result.each{|row| p row}
}

[larskanis]

Cool! I'll use your gem to write proper test cases for ruby-pg.

[ymmtmdk]

Thank you. Naruse-san and bundler are really cool. : )

[meoooh]

Is there any update?

[larskanis]

This is fixed in commit https://bitbucket.org/ged/ruby-pg/commits/f0b7f99 and released as part of pg-0.18.0.

[meoooh]

thank you! @larskanis

[mtarnovan]

I'm still seeing this error in a Rails project using 0.18.1. Any ideas?

[JacobEvelyn]

Same here.

[larskanis]

@mtarnovan , @JacobEvelyn could you please put a stacktrace of the failure into a gist?

[JacobEvelyn]

Looks like I was only getting this error when trying to save binary data to a VARCHAR field rather than a BYTEA. Changing the field type worked for me.