[BUG] Marshal.dump and Marshal.load fail
Reported by oleg dashevskii | January 30th, 2008 @ 11:36 AM | in 1.0 preview
HEAD pre-cleanup-2983-g98fabc5
$ bin/ci spec/ruby/1.8/core/marshal/dump_spec.rb:
Started
..................................F............................................
1)
Marshal.dump with bignum 2**30 returns a string-serialized version of the given argument FAILED
Expectedi@ to equall+@:
Expectation.fail_with at ./mspec/expectations.rb:10
PositiveOperatorMatcher#== at ./mspec/matchers/base.rb:12
main.__script__ {} at ./spec/ruby/1.8/core/marshal/dump_spec.rb:232
Proc#call at kernel/core/proc.rb:66
SpecRunner#describe {} at ./mspec/runner/runner.rb:147
Array#each at kernel/core/array.rb:557
SpecRunner#describe at ./mspec/runner/runner.rb:156
Object#describe at ./mspec/runner/object.rb:11
main.__script__ at ./spec/ruby/1.8/core/marshal/dump_spec.rb:574
CompiledMethod#as_script at kernel/core/compiled_method.rb:206
Compile.single_load at kernel/core/compile.rb:214
Compile.unified_load {} at kernel/core/compile.rb:133
Array#each at kernel/core/array.rb:557
Compile.unified_load at kernel/core/compile.rb:113
Kernel(Object)#load at kernel/core/compile.rb:364
main.__script__ {} at tmp/last_ci.rb:56
Array#each at kernel/core/array.rb:557
main.__script__ at tmp/last_ci.rb:64
CompiledMethod#as_script at kernel/core/compiled_method.rb:206
Compile.single_load at kernel/core/compile.rb:214
Compile.load_from_extension at kernel/core/compile.rb:291
main.__script__ at kernel/loader.rb:176
Finished in 0.222843 seconds
79 examples, 88 expectations, 1 failure, 0 errors
Rubinius dumps 2**30 as:
04 08 69 04 00 00 00 40
What expected is:
04 08 6c 2b 07 00 00 00 40
Corresponding Marshal.load example also fails:
Marshal.load with serialized fixnum -2**30 returns a construction of the argument FAILED
Expectedl-@ to equali��
And there's more:
Marshal.load with serialized bignum -(2**31 - 1) returns a construction of the argument FAILED
Expectedi�� to equall-���:
Comments and changes to this ticket
-
Eero Saynatkari January 30th, 2008 @ 08:41 PM
- → State changed from new to open
Yeah, I am seeing the same. 64-bit issue, it looks like.
-
oleg dashevskii May 2nd, 2008 @ 01:41 PM
- → Title changed from [BUG] Marshal.dump and Marshal.load fail to [BUG] 2**30.class.should == Bignum, being Fixnum on x86_64
This is actually due to failing spec/core/bignum/bignum_spec.rb:
~/work/rubinius% bin/mspec spec/core/bignum/bignum_spec.rb Started FF 1) Bignum has positive threshold value 2 ** 29 FAILED Expected Fixnum to equal Bignum: Expectation.fail_with at ./mspec/expectations.rb:10 PositiveOperatorMatcher#== at ./mspec/matchers/base.rb:15 main.__script__ {} at ./spec/core/bignum/bignum_spec.rb:6 Proc#call at kernel/core/proc.rb:66 SpecRunner#describe {} at ./mspec/runner/runner.rb:147 Array#each at kernel/core/array.rb:557 SpecRunner#describe at ./mspec/runner/runner.rb:156 Object#describe at ./mspec/runner/object.rb:11 main.__script__ at ./spec/core/bignum/bignum_spec.rb:3 CompiledMethod#as_script at kernel/core/compiled_method.rb:206 Compile.single_load at kernel/core/compile.rb:214 Compile.unified_load {} at kernel/core/compile.rb:133 Array#each at kernel/core/array.rb:557 Compile.unified_load at kernel/core/compile.rb:113 Kernel(Object)#load at kernel/core/compile.rb:364 main.__script__ {} at tmp/last_mspec.rb:15 Array#each at kernel/core/array.rb:557 main.__script__ at tmp/last_mspec.rb:20 CompiledMethod#as_script at kernel/core/compiled_method.rb:206 Compile.single_load at kernel/core/compile.rb:214 Compile.load_from_extension at kernel/core/compile.rb:291 main.__script__ at kernel/loader.rb:176 2) Bignum has negative threshold value -(2 ** 29) FAILED Expected Fixnum to equal Bignum: Expectation.fail_with at ./mspec/expectations.rb:10 PositiveOperatorMatcher#== at ./mspec/matchers/base.rb:15 main.__script__ {} at ./spec/core/bignum/bignum_spec.rb:14 Proc#call at kernel/core/proc.rb:66 SpecRunner#describe {} at ./mspec/runner/runner.rb:147 Array#each at kernel/core/array.rb:557 SpecRunner#describe at ./mspec/runner/runner.rb:156 Object#describe at ./mspec/runner/object.rb:11 main.__script__ at ./spec/core/bignum/bignum_spec.rb:3 CompiledMethod#as_script at kernel/core/compiled_method.rb:206 Compile.single_load at kernel/core/compile.rb:214 Compile.unified_load {} at kernel/core/compile.rb:133 Array#each at kernel/core/array.rb:557 Compile.unified_load at kernel/core/compile.rb:113 Kernel(Object)#load at kernel/core/compile.rb:364 main.__script__ {} at tmp/last_mspec.rb:15 Array#each at kernel/core/array.rb:557 main.__script__ at tmp/last_mspec.rb:20 CompiledMethod#as_script at kernel/core/compiled_method.rb:206 Compile.single_load at kernel/core/compile.rb:214 Compile.load_from_extension at kernel/core/compile.rb:291 main.__script__ at kernel/loader.rb:176 Finished in 0.078934 seconds 2 examples, 2 expectations, 2 failures, 0 errors2**30 has Fixnum class (not Bignum) and gets dumped as such.
-
oleg dashevskii May 2nd, 2008 @ 01:42 PM
- → Title changed from [BUG] 2**30.class.should == Bignum, being Fixnum on x86_64 to [BUG] core/bignum/bignum_spec.rb isn't 64-bit friendly.
Well, MRI seems to also fail on this one.
On 64-bit MRI's threshold between Fixnum and Bignum is not 2**29, but 2**62:
irb(main):013:0> (2**62).class => Bignum irb(main):014:0> (-1+2**62).class => Fixnum(that's MRI's irb)
And here's rubinius:
irb(main):002:0> (2**30).class => Fixnum irb(main):003:0> (2**31).class => Bignum -
Dirkjan Bussink February 5th, 2008 @ 02:37 PM
- → State changed from open to resolved
./bin/ci passes for 64 bit as of 1a8c9966fa...
Fixnum is now also MRI compatible on 64 bit
-
Eero Saynatkari May 5th, 2008 @ 03:30 AM
- → Assigned user changed from to Eero Saynatkari
- → Title changed from [BUG] core/bignum/bignum_spec.rb isn't 64-bit friendly. to [BUG] Marshal.dump and Marshal.load fail
Old, closed.
Please Login or create a free account to add a new comment.
You can update this ticket by sending an email to from your email client. (help)
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
