Bug #4217: irb exits unexpectedly with non-ascii Regexp on Windows

• Status: Closed
• Priority: Normal
• Assignee: -
• Target version: 1.9.3
• ruby -v: ruby 1.9.3dev (2010-12-28 trunk 30406) [i386-mswin32_90]

[phasis68 (Heesob Park)]

=begin
C:\work>irb
irb(main):001:0> Regexp.new("\xFF")
RegexpError: c:/usr/lib/ruby/1.9.1/irb.rb:168:in write': "\xFF" on CP949 (Encoding::InvalidByteSequenceError)
from c:/usr/lib/ruby/1.9.1/irb.rb:168:inprint'
from c:/usr/lib/ruby/1.9.1/irb.rb:168:in block (2 levels) in eval_input'
from c:/usr/lib/ruby/1.9.1/irb.rb:273:insignal_status'
from c:/usr/lib/ruby/1.9.1/irb.rb:156:in block in eval_input'
from c:/usr/lib/ruby/1.9.1/irb/ruby-lex.rb:243:inblock (2 levels) in each_top_level_statement'
from c:/usr/lib/ruby/1.9.1/irb/ruby-lex.rb:229:in loop'
from c:/usr/lib/ruby/1.9.1/irb/ruby-lex.rb:229:inblock in each_top_level_statement'
from c:/usr/lib/ruby/1.9.1/irb/ruby-lex.rb:228:in catch'
from c:/usr/lib/ruby/1.9.1/irb/ruby-lex.rb:228:ineach_top_level_statement'
from c:/usr/lib/ruby/1.9.1/irb.rb:155:in eval_input'
from c:/usr/lib/ruby/1.9.1/irb.rb:70:inblock in start'
from c:/usr/lib/ruby/1.9.1/irb.rb:69:in catch'
from c:/usr/lib/ruby/1.9.1/irb.rb:69:instart'
from c:/usr/bin/irb.bat:19:in `'
C:\work>

C:\work>irb
irb(main):001:0> /가\xFF/
SyntaxError: c:/usr/lib/ruby/1.9.1/irb.rb:168:in write': "\xB0" to UTF-8 in conversion from ASCII-8BIT to UTF-8 to UTF-16LE (Encoding::UndefinedConversionError)
from c:/usr/lib/ruby/1.9.1/irb.rb:168:inprint'
from c:/usr/lib/ruby/1.9.1/irb.rb:168:in block (2 levels) in eval_input'
from c:/usr/lib/ruby/1.9.1/irb.rb:273:insignal_status'
from c:/usr/lib/ruby/1.9.1/irb.rb:156:in block in eval_input'
from c:/usr/lib/ruby/1.9.1/irb/ruby-lex.rb:243:inblock (2 levels) in each_top_level_statement'
from c:/usr/lib/ruby/1.9.1/irb/ruby-lex.rb:229:in loop'
from c:/usr/lib/ruby/1.9.1/irb/ruby-lex.rb:229:inblock in each_top_level_statement'
from c:/usr/lib/ruby/1.9.1/irb/ruby-lex.rb:228:in catch'
from c:/usr/lib/ruby/1.9.1/irb/ruby-lex.rb:228:ineach_top_level_statement'
from c:/usr/lib/ruby/1.9.1/irb.rb:155:in eval_input'
from c:/usr/lib/ruby/1.9.1/irb.rb:70:inblock in start'
from c:/usr/lib/ruby/1.9.1/irb.rb:69:in catch'
from c:/usr/lib/ruby/1.9.1/irb.rb:69:instart'
from c:/usr/bin/irb.bat:19:in `'
C:\work>

I found that this bug is releated with rb_w32_write_console function.
Here is a possible patch.

--- win32.c 2010-12-28 13:59:30.000000000 +0900
+++ win32.c.new 2010-12-28 14:00:18.000000000 +0900
@@ -5312,7 +5312,7 @@
!rb_econv_has_convpath_p(rb_enc_name(rb_enc_get(str)), "UTF-16LE"))
return -1L;

• str = rb_str_encode(str, rb_enc_from_encoding(rb_enc_find("UTF-16LE")), 0,
• str = rb_str_encode(str, rb_enc_from_encoding(rb_enc_find("UTF-16LE")), ECONV_INVALID_REPLACE|ECONV_UNDEF_REPLACE, Qnil); if (!WriteConsoleW(handle, (LPWSTR)RSTRING_PTR(str), RSTRING_LEN(str)/2, &reslen, NULL)) { =end

[usa (Usaku NAKAMURA)]

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

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

=end

[phasis68 (Heesob Park)]

=begin
I think r30412 is incomplete.

After applying r30412, while the second case is fixed, the first case is still exist.

irb(main):001:0> Regexp.new("\xFF")
RegexpError: c:/usr/lib/ruby/1.9.1/irb.rb:168:in write': "\xFF" on CP949 (Encoding::InvalidByteSequenceError)
from c:/usr/lib/ruby/1.9.1/irb.rb:168:inprint'
from c:/usr/lib/ruby/1.9.1/irb.rb:168:in block (2 levels) in eval_input'
from c:/usr/lib/ruby/1.9.1/irb.rb:273:insignal_status'
from c:/usr/lib/ruby/1.9.1/irb.rb:156:in block in eval_input'
from c:/usr/lib/ruby/1.9.1/irb/ruby-lex.rb:243:inblock (2 levels) in each_top_level_statement'
from c:/usr/lib/ruby/1.9.1/irb/ruby-lex.rb:229:in loop'
from c:/usr/lib/ruby/1.9.1/irb/ruby-lex.rb:229:inblock in each_top_level_statement'
from c:/usr/lib/ruby/1.9.1/irb/ruby-lex.rb:228:in catch'
from c:/usr/lib/ruby/1.9.1/irb/ruby-lex.rb:228:ineach_top_level_statement'
from c:/usr/lib/ruby/1.9.1/irb.rb:155:in eval_input'
from c:/usr/lib/ruby/1.9.1/irb.rb:70:inblock in start'
from c:/usr/lib/ruby/1.9.1/irb.rb:69:in catch'
from c:/usr/lib/ruby/1.9.1/irb.rb:69:instart'
from c:/usr/bin/irb.bat:19:in `'

C:\work>irb
irb(main):001:0> /가\xFF/
SyntaxError: (irb):1: invalid multibyte escape: /가\xFF/
from c:/usr/bin/irb.bat:19:in `'
irb(main):002:0>

=end

[phasis68 (Heesob Park)]

=begin
Hi,

2011/1/3 U.Nakamura [e-mail]:

Hello,

In message "[ruby-core:33983] [Ruby 1.9-Bug#4217] irb exits unexpectedly with non-ascii Regexp on Windows"
   on Dec.29,2010 10:32:06, [e-mail] wrote:
| I think r30412 is incomplete.

Sorry, I missed a changeset on r30412.
I've committed it on r30418.  Check it, please.

I checked it, it works fine.

BTW, what happend to http://redmine.ruby-lang.org ?
I cannot access redmine. And it's not just me.
http://www.downforeveryoneorjustme.com/redmine.ruby-lang.org

Regards,
Park Heesob

=end

[usa (Usaku NAKAMURA)]

=begin
Hello,

In message "[ruby-core:33983] [Ruby 1.9-Bug#4217] irb exits unexpectedly with non-ascii Regexp on Windows"
on Dec.29,2010 10:32:06, [e-mail] wrote:
| I think r30412 is incomplete.

Sorry, I missed a changeset on r30412.
I've committed it on r30418. Check it, please.

Regards,
--
U.Nakamura [e-mail]

=end

[usa (Usaku NAKAMURA)]

=begin
Hello,

In message "[ruby-core:34028] Re: [Ruby 1.9-Bug#4217] irb exits unexpectedly with non-ascii Regexp on Windows"
on Jan.03,2011 16:02:26, [e-mail] wrote:
| > Sorry, I missed a changeset on r30412.
| > I've committed it on r30418. ?Check it, please.
| >
| I checked it, it works fine.

Thank you for your confirmation.

| BTW, what happend to http://redmine.ruby-lang.org ?
| I cannot access redmine. And it's not just me.
| http://www.downforeveryoneorjustme.com/redmine.ruby-lang.org

I'm not the manager of ruby servers, so this is a mere guess,
the power failure and cutting the line have occured in the
region where the servers exist becase uf the heavy snow
of last week.
Unfortunately, all Japanese are on vacation of the new year,
so time is expected to be taken for restoration.
I guess that it will take more several days for restoration.

Regards,
--
U.Nakamura [e-mail]

=end