From mboxrd@z Thu Jan 1 00:00:00 1970 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 04 Jun 2008 12:12:39 -0700 Subject: [sup-talk] Checking for unexpected types In-Reply-To: <2747A2E5-4957-45B5-AC5F-605A3196F874@gmail.com> References: <2747A2E5-4957-45B5-AC5F-605A3196F874@gmail.com> Message-ID: <1212605536-sup-2572@entry> Reformatted excerpts from fedzor's message of 2008-06-04: > --- SystemExit from thread: main > undefined method `each' for false:FalseClass > /Users/ari/local//lib/ruby/gems/1.8/gems/sup-0.5/lib/sup.rb:64:in > `select' > /Users/ari/local//lib/ruby/gems/1.8/gems/sup-0.5/lib/sup/buffer.rb: > 31:in `nonblocking_getch' > /Users/ari/local//lib/ruby/gems/1.8/gems/sup-0.5/bin/sup:227 > /Users/ari/local/lib/ruby/gems/1.8/bin/sup:19:in `load' > /Users/ari/local/lib/ruby/gems/1.8/bin/sup:19 > > I get way too many of these. Maybe it's because I'm using gmail and > it just gets sooooooo many hits that some get lost, but I'm tired of > it. I want to switch over to sup full-time, but I can't because it > crashes often, when I scroll down too much or when it tries to load a > lot of emails. Interesting. Sup rarely crashes for me any more, and I make it work pretty hard. I don't use IMAP, so that might be the difference. (Pretty much everyone seems to have problems with the Ruby IMAP library.) I don't think typechecking is the right way to handle this. Typically a NME is a symptom of something else being wrong (like NPEs in Java), so fixing that is just symptomatic medicine. The backtrace above doesn't make any sense. 'Undefined method' generates a NoMethodError, not a SystemExit, and there's no select method in sup.rb. This is a sign that something weird is happening with threads and exception handling. So, if you can make this happen consistently, then I would recommend trying to track down the source(s) of the problem. Is it just one line? Or is it really a systematic problem throughout Sup? Things to try: - apply commit 7f2af9ac8bc70ff41b0dc64eccd068118abe19f2, which I've just merged into master and next. This requires fastthread, and adds some synchronization around the exception handling. I've attached the patch for your convenience, though I'm not sure if it will apply cleanly to 0.5. This might help produce intelligence backtraces. - Run sup with -n (which turns off threading) and see if you can get a real backtrace for the above error. - Use offlineimap and see if you can still induce the exceptions. -- William -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-exception-cleanup-synchronize-access-and-require-f.patch Type: application/octet-stream Size: 3228 bytes Desc: not available URL: