Backport #2404: [PATCH] force_encoding on frozen string in gem_prelude

• Status: Closed
• Assignee: yugui (Yuki Sonoda)

[rubys (Sam Ruby)]

=begin
Simply entering any gem command or even irb on Ubuntu produces the following:

Error loading gem paths on load path in gem_prelude
can't modify frozen string
internal:gem_prelude:70:in force_encoding' <internal:gem_prelude>:70:in set_home'
internal:gem_prelude:38:in dir' <internal:gem_prelude>:83:in set_paths'
internal:gem_prelude:47:in path' <internal:gem_prelude>:227:in push_all_highest_version_gems_on_load_path'
internal:gem_prelude:301:in `'

Note: on Linux, File::ALT_SEPARATOR=nil, so the gsub will not be executed.

Patch attached.
=end

[rubys (Sam Ruby)]

=begin
Problem only occurs if the GEM_HOME environment variable is set.
=end

[bitsweat (Jeremy Daer)]

=begin
To replicate on any platform:

GEM_HOME=foo ruby -e ''

Verified that the patch fixes it.
=end

[ujihisa (Tatsuhiro Ujihisa)]

• Status changed from Open to Assigned
• Assignee set to drbrain (Eric Hodel)

=begin

=end

[naruse (Yui NARUSE)]

• Category set to core
• Status changed from Assigned to Closed
• Target version set to 1.9.2

=begin
fixed at r25932.
=end

[wayneeseguin (Wayne E. Seguin)]

=begin
This bug is now present and highly invasive in the newly released 1.9.1-p429

 › uname -a
 Linux ams-blm-p0 2.6.18-164.11.1.el5xen #1 SMP Wed Jan 20 08:06:04 EST 2010 x86_64 x86_64 x86_64 GNU/Linux

 › ruby -v
 ruby 1.9.1p429 (2010-07-02 revision 28523) [x86_64-linux]

 › gem --version 
 Error loading gem paths on load path in gem_prelude
 can't modify frozen string
 <internal:gem_prelude>:69:in `force_encoding'
 <internal:gem_prelude>:69:in `set_home'
 <internal:gem_prelude>:38:in `dir'
 <internal:gem_prelude>:76:in `set_paths'
 <internal:gem_prelude>:47:in `path'
 <internal:gem_prelude>:286:in `push_all_highest_version_gems_on_load_path'
 <internal:gem_prelude>:355:in `<compiled>'
 1.3.7

 › irb
 Error loading gem paths on load path in gem_prelude
 can't modify frozen string
 <internal:gem_prelude>:69:in `force_encoding'
 <internal:gem_prelude>:69:in `set_home'
 <internal:gem_prelude>:38:in `dir'
 <internal:gem_prelude>:76:in `set_paths'
 <internal:gem_prelude>:47:in `path'
 <internal:gem_prelude>:286:in `push_all_highest_version_gems_on_load_path'
 <internal:gem_prelude>:355:in `<compiled>'
 ruby-1.9.1-p429 > 

Whereas on the exact same host, same installation method (RVM):

 › uname -a
 Linux ams-blm-p0 2.6.18-164.11.1.el5xen #1 SMP Wed Jan 20 08:06:04 EST 2010 x86_64 x86_64 x86_64 GNU/Linux

 › ruby -v
 ruby 1.9.1p378 (2010-01-10 revision 26273) [x86_64-linux]

 › gem --version 
 1.3.6

 › irb
 ruby-1.9.1-p378 > 

I am able to reproduce on my local as well as the server listed above.
Simply installing p429 triggers the bug.
(Local: ∴ uname -a => Darwin Genius.local 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 i386 i386)

=end

[nobu (Nobuyoshi Nakada)]

• Status changed from Closed to Assigned
• Assignee changed from drbrain (Eric Hodel) to yugui (Yuki Sonoda)
• Priority changed from 5 to Normal

=begin

=end

[sferik (Erik Michaels-Ober)]

=begin
This appears to still be an issue in 1.9.1 at patchlevel 431.

What is the reason why Sam's patch has not yet been merged? Also, why was priority changed high to normal?
=end

[schmurfy (Julien A)]

That is awesome to see the latest ruby 1.9.1 version crippled with a bug reported with a patch 1 year ago, was it forgotten or is nobody using 1.9.1 ?

[nobu (Nobuyoshi Nakada)]

Nobody.

[schmurfy (Julien A)]

Sadly I am, and for now I cannot switch to 1.9.2 since our application does not work on it as is ...

[cczona (C. Zona)]

Ping. Can we please get this patch merged to 1.9.1? Thanks.

[jeremyevans0 (Jeremy Evans)]

• Status changed from Assigned to Closed