Marshal.dump does not serialize an Exception's backtrace

[vincent.isambart@…]

The following code:

begin
  raise 'test'
rescue Exception => e
  p e.backtrace
  p Marshal.load(Marshal.dump(e)).backtrace
end

displays:

["untitled.rb:2:in `<main>'"]
nil

instead of: (Ruby 1.9)

["untitled.rb:2:in `<main>'"]
["untitled.rb:2:in `<main>'"]

If you look at the (binary) result of Marshal.dump(e), you can indeed see that it does not include the backtrace in MacRuby.

[jhemmelg@…]

I have been looking into this bug. I have traced the cause to not marshalling out ivars. It looks like this is at least partially due to the fact that strings are UTF-8 only (ticket #742). When I change Marshal's w_object() to output ivars it hits an infinite loop marshalling out the string. When a string is marshalled out, it's encoding is marhsalled out as well. The string encoding is a string itself. When that string is marshalled out, it's encoding is marshalled as well. It's turtles all the way down until the stack blows up. In MatzRuby there is a short circuit for US-ASCII and UTF-8 that breaks this recursion.

I think we need to resolve handling string encodings (ticket #742) before this bug can be fixed. I also think this needs to be a 1.0 bug.

[jhemmelg@…]

OK. The problem was actually in the w_objivar function in marshal.c. In the 1.9.2 codebase this function marshals out all ivars, regardless of whether they have a single '@' character at the beginning or not. In macruby the code ends up calling ivar_i in variable.c to determine what ivars to marshal out. This function does discriminate and only returns ivars that start with a '@' character.

The problem with strings mentioned above still exists but is probably better dealt with when fixing the string encoding issues.

[jhemmelg@…]

patch file

[watson1978@…]

Fixed with  https://github.com/MacRuby/MacRuby/commit/9cad55f996ea489e8aa8224113019a2f66385dad