Backport #2404
closed[PATCH] force_encoding on frozen string in gem_prelude
Description
=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
Files
Updated by rubys (Sam Ruby) almost 15 years ago
=begin
Problem only occurs if the GEM_HOME environment variable is set.
=end
Updated by bitsweat (Jeremy Daer) almost 15 years ago
=begin
To replicate on any platform:
GEM_HOME=foo ruby -e ''
Verified that the patch fixes it.
=end
Updated by ujihisa (Tatsuhiro Ujihisa) almost 15 years ago
- Status changed from Open to Assigned
- Assignee set to drbrain (Eric Hodel)
=begin
=end
Updated by naruse (Yui NARUSE) almost 15 years ago
- Category set to core
- Status changed from Assigned to Closed
- Target version set to 1.9.2
=begin
fixed at r25932.
=end
Updated by wayneeseguin (Wayne E. Seguin) over 14 years ago
=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
Updated by nobu (Nobuyoshi Nakada) over 14 years ago
- Status changed from Closed to Assigned
- Assignee changed from drbrain (Eric Hodel) to yugui (Yuki Sonoda)
- Priority changed from 5 to Normal
=begin
=end
Updated by sferik (Erik Michaels-Ober) over 13 years ago
=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
Updated by schmurfy (Julien A) over 13 years ago
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 ?
Updated by schmurfy (Julien A) over 13 years ago
Sadly I am, and for now I cannot switch to 1.9.2 since our application does not work on it as is ...
Updated by cczona (C. Zona) about 13 years ago
Ping. Can we please get this patch merged to 1.9.1? Thanks.
Updated by jeremyevans0 (Jeremy Evans) over 5 years ago
- Status changed from Assigned to Closed