Marshal.dump yields different value after adding/removing instance variables
(and disagrees with MRI)
-----------------------------------------------------------------------------------------------------
Key: JRUBY-6182
URL: https://jira.codehaus.org/browse/JRUBY-6182
Project: JRuby
Issue Type: Bug
Components: Ruby 1.9.2
Affects Versions: JRuby 1.6.5
Environment: Windows 7, 32-bit Java 1.6.0_29
Reporter: Matt Keveney
Assignee: Thomas E Enebo
I'm not sure whether this is a bug in JRuby, or merely an oddity that surfaced
due to an unconventional use of Marshal.
JRuby with --1.9:
irb(main):001:0> h = {}
=> {}
irb(main):002:0> Marshal.dump h
=> "\x04\b{\x00"
irb(main):003:0> h.instance_eval { @myvar = 1234 }
=> 1234
irb(main):004:0> Marshal.dump h
=> "\x04\bI{\x00\x06:\v@myvari\x02\xD2\x04"
irb(main):005:0> h.instance_eval { remove_instance_variable :@myvar }
=> 1234
irb(main):006:0> Marshal.dump h
=> "\x04\bI{\x00\x00"
Note that h is dumped differently after the instance variable has been
removed, though this bytestream will still yield an equivalent object. It
seems to be specifying a zero-length list of instance variables.
MRI version 1.9.2
irb(main):001:0> h = {}
=> {}
irb(main):002:0> Marshal.dump h
=> "\x04\b{\x00"
irb(main):003:0> h.instance_eval { @myvar = 1234 }
=> 1234
irb(main):004:0> Marshal.dump h
=> "\x04\bI{\x00\x06:\v@myvari\x02\xD2\x04"
irb(main):005:0> h.instance_eval { remove_instance_variable :@myvar }
=> 1234
irb(main):006:0> Marshal.dump h
=> "\x04\b{\x00"
Note that MRI completely removes the instance variable tag from the byte
stream.
I found this this using Nanoc with Jruby. Nanoc computes a SHA1 hash on the
Marshal.dump output to detect object alterations from one run to the next. This
strategy only works if Marshal is guaranteed to emit an _identical_ bytestream
for equivalent objects.
Should Marshal be expected to do so? ...or is Nanoc expecting too much?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email