Backport #8276
closedMarshal.load modifies restored object after calling #marshal_load
Description
Given this code, a simple class freezing instances on creation (so they are immutable):
class T
def initialize(data)
@data = data
freeze
end
def marshal_dump
@data
end
def marshal_load data
initialize(data)
end
end
t = T.new("dd")
s = Marshal.dump(t)
p Marshal.load(s) # => ...:in `load': can't modify frozen T (RuntimeError)
Freezing on creation from Marshal is needed to ensure immutability and it seems the right place to do it.
It used to work (ruby 2.0.0dev (2012-07-15 trunk 36395) [x86_64-darwin10.8.0] did fine).
The backtrace:
(gdb) bt
#0 rb_raise (exc=4304355040, fmt=0x1001be828 "can't modify frozen %s") at error.c:1810
#1 0x000000010004344f in rb_error_frozen (what=<value temporarily unavailable, due to optimizations>) at error.c:2020
#2 0x0000000100004600 in rb_enc_associate_index (obj=<value temporarily unavailable, due to optimizations>, idx=1) at encoding.c:749
#3 0x000000010008233b in r_ivar (obj=4320803800, has_encoding=0x0, arg=0x1006b84b0) at marshal.c:1374
#4 0x00000001000811f1 in r_object0 (arg=0x1006b84b0, ivp=<value temporarily unavailable, due to optimizations>, extmod=8) at marshal.c:1475
#5 0x00000001000821ad in r_object [inlined] () at /Users/benoitdaloze/EREGONMS/Ruby/git/ruby/marshal.c:1890
#6 0x00000001000821ad in marshal_load (argc=<value temporarily unavailable, due to optimizations>, argv=<value temporarily unavailable, due to optimizations>) at marshal.c:1978
...
Updated by nobu (Nobuyoshi Nakada) almost 11 years ago
- Status changed from Open to Closed
- % Done changed from 0 to 100
This issue was solved with changeset r40366.
Benoit, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.
marshal.c: no duplicated encoding
- marshal.c (w_object): do not dump encoding which is dumped with
marshal_dump data. [ruby-core:54334] [Bug #8276]
Updated by nobu (Nobuyoshi Nakada) almost 11 years ago
- Tracker changed from Bug to Backport
- Project changed from Ruby master to Backport200
- Category deleted (
core) - Status changed from Closed to Assigned
- Assignee set to nagachika (Tomoyuki Chikanaga)
Updated by nobu (Nobuyoshi Nakada) almost 11 years ago
Note that returning frozen object from marshal_load is wrong in common.
In this particular case, removed excess encoding information because it is duplicated to marshal_dump data, but the other instance variables are set after marshal_load.
Your code has a potential bug and should separate marshal_dump and initialize.
Updated by Eregon (Benoit Daloze) almost 11 years ago
nobu (Nobuyoshi Nakada) wrote:
Note that returning frozen object from marshal_load is wrong in common.
In this particular case, removed excess encoding information because it is duplicated to marshal_dump data, but the other instance variables are set after marshal_load.
Your code has a potential bug and should separate marshal_dump and initialize.
How would you reliably freeze the object again then?
Should it be a feature of Marshal?
Updated by nagachika (Tomoyuki Chikanaga) almost 11 years ago
r40559 seems a related commit.
Updated by Eregon (Benoit Daloze) almost 11 years ago
nagachika (Tomoyuki Chikanaga) wrote:
r40559 seems a related commit.
Indeed. I still do not understand all the details of Marshal though and why instance variables are touched for classes with marshal_{dump,load}.
Anyway, for frozen objects it feels righter to use _dump/self._load which allows to freeze easily at initialization.
Updated by naruse (Yui NARUSE) almost 8 years ago
- Status changed from Assigned to Rejected