[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