Backport #2404
closed
[PATCH] force_encoding on frozen string in gem_prelude
Added by rubys (Sam Ruby) over 14 years ago.
Updated about 5 years ago.
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
patch (476 Bytes)
patch |
|
rubys (Sam Ruby), 11/26/2009 05:46 AM
|
|
=begin
Problem only occurs if the GEM_HOME environment variable is set.
=end
=begin
To replicate on any platform:
GEM_HOME=foo ruby -e ''
Verified that the patch fixes it.
=end
- Status changed from Open to Assigned
- Assignee set to drbrain (Eric Hodel)
- Category set to core
- Status changed from Assigned to Closed
- Target version set to 1.9.2
=begin
fixed at r25932.
=end
=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
- Status changed from Closed to Assigned
- Assignee changed from drbrain (Eric Hodel) to yugui (Yuki Sonoda)
- Priority changed from 5 to Normal
=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
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 ?
Sadly I am, and for now I cannot switch to 1.9.2 since our application does not work on it as is ...
Ping. Can we please get this patch merged to 1.9.1? Thanks.
- Status changed from Assigned to Closed
Also available in: Atom
PDF
Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0