Sorry it's taken me so long to get back to this. Reformatted excerpts from Ben Gamari's message of 2009-09-16: > Thread#join: deadlock 0x7f592eec4d78 - mutual join(0x7f592f01d6e8) > /opt/exp/sup/lib/sup/message.rb:240:in `select' > /opt/exp/sup/lib/sup/buffer.rb:35:in `nonblocking_getch' > /usr/bin/sup:213 > > However, at this point during debugging I happened to pipe stderr to a > file and accidentally found that most of the backtrace was actually > being hidden by curses. Examining the full output on stderr reveals, > > /usr/bin/sup:213(eval):3:in `synchronize': Thread#join: deadlock > 0x7f4d5da565c0 - mutual join(0x7f4d5daf8be0) (ThreadError) > from (eval):3:in `raw_header' > from /opt/exp/sup/lib/sup/imap.rb:98:in `load_header'
I definitely am not sure why there's a deadlock happening, but I am guessing, based on the line numbers in that first exception, that it's being triggered by an underlying problem with the source. If you run sup with -n, does that change anything? (Or produce a better exception?) > Anyways, this is the current status of things on my machine. William, do > you have any ideas what might cause such a backtrace. At this point > classes have started and I really have no more time to devote to > getting sup working. If there isn't a fairly simple solution here I guess > I'll just need to stick with mutt (ugh). Anyways, thanks for your work. Well, there's a workaround, which is to switch over to an offlineimap setup where your Gmail is mirrored locally and Sup reads the mirror (which is what you want anyways if you're serious about using Sup with an IMAP client). I don't know what's causing the deadlock, but I will try and reproduce it on my end. -- William <[email protected]> _______________________________________________ sup-talk mailing list [email protected] http://rubyforge.org/mailman/listinfo/sup-talk
