[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Invalid encoding symbol when doing Marshal.load



Hi,

I've been searching a bit through some old mail and suddenly encountered
the following error:

  --- EncodingError from thread: load threads for thread-index-mode
  invalid encoding symbol
  /home/gaute/dev/ruby/sup.git/lib/sup/index.rb:796:in `load'
  /home/gaute/dev/ruby/sup.git/lib/sup/index.rb:796:in `entry'
  /home/gaute/dev/ruby/sup.git/lib/sup/index.rb:571:in `get_entry'
  /home/gaute/dev/ruby/sup.git/lib/sup/index.rb:200:in `block in build_message'
  /usr/lib/ruby/1.9.1/monitor.rb:201:in `mon_synchronize'
  /home/gaute/dev/ruby/sup.git/lib/sup/index.rb:579:in `synchronize'
  /home/gaute/dev/ruby/sup.git/lib/sup/index.rb:200:in `build_message'
  /home/gaute/dev/ruby/sup.git/lib/sup/index.rb:155:in `block (2 levels) in each_id_by_date'
  /home/gaute/dev/ruby/sup.git/lib/sup/thread.rb:338:in `call'
  /home/gaute/dev/ruby/sup.git/lib/sup/thread.rb:338:in `block in load_n_threads'
  /home/gaute/dev/ruby/sup.git/lib/sup/index.rb:155:in `block in each_id_by_date'
  /home/gaute/dev/ruby/sup.git/lib/sup/index.rb:250:in `block in each_id'
  /home/gaute/dev/ruby/sup.git/lib/sup/index.rb:250:in `each'
  /home/gaute/dev/ruby/sup.git/lib/sup/index.rb:250:in `each_id'
  /home/gaute/dev/ruby/sup.git/lib/sup/index.rb:155:in `each_id_by_date'
  /home/gaute/dev/ruby/sup.git/lib/sup/thread.rb:334:in `load_n_threads'
  /home/gaute/dev/ruby/sup.git/lib/sup/modes/thread-index-mode.rb:643:in `load_n_threads'
  (eval):12:in `load_n_threads'
  /home/gaute/dev/ruby/sup.git/lib/sup/modes/thread-index-mode.rb:627:in `block in load_n_threads_background'
  /home/gaute/dev/ruby/sup.git/lib/sup.rb:78:in `block in reporting_thread'

running latest 'next'. I've tried to experiment a bit with it, but
haven't found a solution. Trying to encode data, or force_encode the
data to UTF-8.

This happens when listing some old mail, so it could possibly be an
issue with data not _stored_ correctly in the first place.

I still haven't figured out a way to handle the exception and still get
the message structure de-serialized. Any suggestions?

Best regards,
Gaute