Subject: Re: [sup-talk] Crash while in thread-view-mode

From: William Morgan <[email-masked]>
Date: Thu, 15 Oct 2009 05:46:51 -0700

Reformatted excerpts from Ben Gamari's message of 2009-10-07:
> There must be a better way to deal with these invalid ids than
> crashing. Is there any reason this needs to be a show-stopping event?

This is probably a symptom of some thread protection issues. You're
right, there's no reason this needs to crash Sup. You could apply this:

diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb
index 82f258b..17d5836 100644
--- a/lib/sup/modes/thread-index-mode.rb
+++ b/lib/sup/modes/thread-index-mode.rb
@@ -222,7 +222,7 @@ EOS
   def update
     @mutex.synchronize do
       ## let's see you do THIS in python
-      @threads = @ts.threads.select { |t| !@hidden_threads[t] }.sort_by { |t| [t.date, t.first.id] }.reverse
+      @threads = @ts.threads.select { |t| !@hidden_threads[t] }.select { |t| t.first }.sort_by { |t| [t.date, t.first.id] }.reverse
       @size_widgets = @threads.map { |t| size_widget_for_thread t }
       @size_widget_width = @size_widgets.max_of { |w| w.display_length }
     end
-- 
William <[email-masked]>
_______________________________________________
sup-talk mailing list
[email-masked]
http://rubyforge.org/mailman/listinfo/sup-talk

---

From: William Morgan <[email-masked]>
Date: Thu, 15 Oct 2009 08:16:36 -0700

Reformatted excerpts from Guillaume Quintard's message of 2009-10-15:
> (and I love the Python comment, even if I have no effing idea of what
> the code could mean.)

It refers to the fact that Python programs don't have bugs.
-- 
William <[email-masked]>
_______________________________________________
sup-talk mailing list
[email-masked]
http://rubyforge.org/mailman/listinfo/sup-talk

---

From: Ben Gamari <[email-masked]>
Date: Wed, 07 Oct 2009 18:46:39 -0400

Excerpts from Ben Gamari's message of Wed Oct 07 15:56:43 -0400 2009:
> After going through the process of rebuilding my index (again), things
> seem to be more stable (for now). 

Well, this was true for a while. Unfortunately, it seems that my LKML
label is yet again crashing sup. The exception is very similar to that
which I experienced prior to rebuilding. It's quite reproducible, always
crashing after loading a few hundred messages or so. There must be a
better way to deal with these invalid ids than crashing. Is there any
reason this needs to be a show-stopping event? Thanks,

- Ben

--- RuntimeError from thread: load threads for thread-index-mode
wrong id called on nil
/opt/exp/sup/lib/sup.rb:17:in `id'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `update'
/opt/exp/sup/lib/sup/hook.rb:121:in `sort_by'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `each'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `sort_by'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `update'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:223:in `synchronize'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:223:in `update'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:628:in `__unprotected_load_n_threads'
/opt/exp/sup/lib/sup/thread.rb:334:in `load_n_threads'
/opt/exp/sup/lib/sup/xapian_index.rb:117:in `each_id_by_date'
/opt/exp/sup/lib/sup/xapian_index.rb:110:in `each_id'
/opt/exp/sup/lib/sup/xapian_index.rb:110:in `each'
/opt/exp/sup/lib/sup/xapian_index.rb:110:in `each_id'
/opt/exp/sup/lib/sup/xapian_index.rb:117:in `each_id_by_date'
/opt/exp/sup/lib/sup/thread.rb:328:in `load_n_threads'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:625:in `__unprotected_load_n_threads'
(eval):12:in `load_n_threads'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:609:in `load_n_threads_background'
/opt/exp/sup/lib/sup.rb:77:in `reporting_thread'
/opt/exp/sup/lib/sup.rb:75:in `initialize'
/opt/exp/sup/lib/sup.rb:75:in `new'
/opt/exp/sup/lib/sup.rb:75:in `reporting_thread'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:679:in `__unprotected_load_threads'
(eval):12:in `load_threads'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:81:in `initialize'
/opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:22:in `call'
/opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:22:in `initialize'
/opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:22:in `each'
/opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:22:in `initialize'
/opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:19:in `new'
/opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:19:in `initialize'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:54:in `initialize'
/opt/exp/sup/lib/sup/modes/label-search-results-mode.rb:9:in `initialize'
/opt/exp/sup/lib/sup/modes/label-search-results-mode.rb:32:in `new'
/opt/exp/sup/lib/sup/modes/label-search-results-mode.rb:32:in `spawn_nicely'
/opt/exp/sup/lib/sup/buffer.rb:350:in `spawn_unless_exists'
/opt/exp/sup/lib/sup/util.rb:520:in `send'
/opt/exp/sup/lib/sup/util.rb:520:in `method_missing'
/opt/exp/sup/lib/sup/modes/label-search-results-mode.rb:32:in `spawn_nicely'
/opt/exp/sup/lib/sup/modes/label-list-mode.rb:103:in `select_label'
/opt/exp/sup/lib/sup/mode.rb:51:in `send'
/opt/exp/sup/lib/sup/mode.rb:51:in `handle_input'
/opt/exp/sup/lib/sup/buffer.rb:267:in `handle_input'
/usr/bin/sup:239
_______________________________________________
sup-talk mailing list
[email-masked]
http://rubyforge.org/mailman/listinfo/sup-talk

---

From: Guillaume Quintard <[email-masked]>
Date: Thu, 15 Oct 2009 15:47:00 +0200

Excerpts from William Morgan's message of Thu Oct 15 14:46:51 +0200 2009:
> +      @threads = @ts.threads.select { |t| !@hidden_threads[t] }.select { |t|
> t.first }.sort_by { |t| [t.date, t.first.id] }.reverse
Man, I love you, I can finally use sup again.

Thanks!

-- 
Guillaume

---

From: Ben Gamari <[email-masked]>
Date: Tue, 06 Oct 2009 11:53:18 -0400

Well, it seems like whatever caused the crash earlier did something to
my index. Now any attempt to open a thread-index-mode of my LKML label
(which I was viewing in the earlier crash) causes the client to
immediately crash.

Do any of the sup utilities have any sort of index sanity checker to
find potential causes of this sort of issue? Thanks,

- Ben

/usr/lib64/ruby/1.8/rubygems/custom_require.rb:31:in `sort_by'
/opt/exp/sup/lib/sup/modes/label-search-results-mode.rb:33:in `spawn_nicely'

Excerpts from Ben Gamari's message of Tue Oct 06 11:47:34 -0400 2009:
> I just had sup crash on me while reading a thread. Not really sure what
> to make of the backtrace. Looks like it failed during polling but who
> knows why. Thanks,
> 
> - Ben
>

---

From: Ben Gamari <[email-masked]>
Date: Tue, 06 Oct 2009 12:15:46 -0400

> (which I was viewing in the earlier crash) causes the client to

Hmm, it seems like the problem is spreading. I now come to find out that
another label triggers this same crash (although I guess it's possible
that the intersection of the two labels is non-nil). I tried running a
sup-sync -oc on the relevant sources to no avail. I really don't have
time to devote to debugging this at the moment so it looks like I might
need to take another hiatus from sup. Just as I was starting to get used
to it... sigh. Anyways, if anyone has any ideas for improving things,
let me know. Thanks!

- Ben

---

From: Guillaume Quintard <[email-masked]>
Date: Wed, 7 Oct 2009 10:48:56 +0200

On Wed, Oct 7, 2009 at 8:44 AM, Rich Lane <[email-masked]> wrote:
> You could try running sup with the -n flag to disable threading. The
> major downside is that you have to hit P to poll manually.

That "solves" the problem for me.

---

From: Ben Gamari <[email-masked]>
Date: Thu, 15 Oct 2009 11:03:04 -0400

> right, there's no reason this needs to crash Sup. You could apply this:
Yep, this fixes it. Thank you so much. Now to sort through my backlog of
mail. Thanks again,

- Ben

---

From: Guillaume Quintard <[email-masked]>
Date: Wed, 7 Oct 2009 11:07:47 +0200

> That "solves" the problem for me.

Scratch that, I just relaunched sup, and I still get the wrong id
called on nil error.

---

From: Ben Gamari <[email-masked]>
Date: Tue, 06 Oct 2009 11:47:34 -0400

- Ben

--- RuntimeError from thread: periodic poll
wrong id called on nil
/opt/exp/sup/lib/sup.rb:17:in `id'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `update'
/opt/exp/sup/lib/sup/xapian_index.rb:325:in `sort_by'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `each'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `sort_by'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `update'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:223:in `synchronize'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:223:in `update'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:702:in `add_or_unhide'
/opt/exp/sup/lib/sup/modes/thread-index-mode.rb:188:in `handle_added_update'
/opt/exp/sup/lib/sup/update.rb:26:in `send'
/opt/exp/sup/lib/sup/update.rb:26:in `relay'
/opt/exp/sup/lib/sup/update.rb:26:in `each'
/opt/exp/sup/lib/sup/update.rb:26:in `relay'
/opt/exp/sup/lib/sup/util.rb:520:in `send'
/opt/exp/sup/lib/sup/util.rb:520:in `method_missing'
/opt/exp/sup/lib/sup/poll.rb:181:in `add_new_message'
/opt/exp/sup/lib/sup/poll.rb:124:in `do_poll'
/opt/exp/sup/lib/sup/poll.rb:166:in `each_message_from'
/opt/exp/sup/lib/sup/maildir.rb:160:in `each'
/opt/exp/sup/lib/sup/maildir.rb:157:in `upto'
/opt/exp/sup/lib/sup/maildir.rb:157:in `each'
/opt/exp/sup/lib/sup/util.rb:560:in `send'
/opt/exp/sup/lib/sup/util.rb:560:in `__pass'
/opt/exp/sup/lib/sup/util.rb:547:in `method_missing'
/opt/exp/sup/lib/sup/poll.rb:154:in `each_message_from'
/opt/exp/sup/lib/sup/poll.rb:108:in `do_poll'
/opt/exp/sup/lib/sup/poll.rb:96:in `each'
/opt/exp/sup/lib/sup/poll.rb:96:in `do_poll'
/opt/exp/sup/lib/sup/poll.rb:95:in `synchronize'
/opt/exp/sup/lib/sup/poll.rb:95:in `do_poll'
/opt/exp/sup/lib/sup/util.rb:520:in `send'
/opt/exp/sup/lib/sup/util.rb:520:in `method_missing'
/opt/exp/sup/lib/sup/modes/poll-mode.rb:15:in `poll'
/opt/exp/sup/lib/sup/poll.rb:47:in `poll_with_sources'
/opt/exp/sup/lib/sup/poll.rb:62:in `poll'
/opt/exp/sup/lib/sup/poll.rb:80:in `start'
/opt/exp/sup/lib/sup.rb:77:in `reporting_thread'
/opt/exp/sup/lib/sup.rb:75:in `initialize'
/opt/exp/sup/lib/sup.rb:75:in `new'
/opt/exp/sup/lib/sup.rb:75:in `reporting_thread'
/opt/exp/sup/lib/sup/poll.rb:77:in `start'
/opt/exp/sup/lib/sup/util.rb:520:in `send'
/opt/exp/sup/lib/sup/util.rb:520:in `method_missing'
/usr/bin/sup:204
_______________________________________________
sup-talk mailing list
[email-masked]
http://rubyforge.org/mailman/listinfo/sup-talk

---

From: Mark Alexander <[email-masked]>
Date: Tue, 06 Oct 2009 12:39:08 -0400

> I really don't have
> need to take another hiatus from sup.

You could try running an older version.  I've been using 0.8 at
work, and a May 20 snapshot of next at home, and both have been very
solid.  They're good enough, in fact, that I don't feel the need to
upgrade.  Maybe after the dust settles from all the recent code
churn...
_______________________________________________
sup-talk mailing list
[email-masked]
http://rubyforge.org/mailman/listinfo/sup-talk

---

From: Rich Lane <[email-masked]>
Date: Wed, 07 Oct 2009 02:44:34 -0400

> to it... sigh. Anyways, if anyone has any ideas for improving things,

I've been seeing this crash for a long time. I think it's a race between
the poll thread / load-more-threads thread and the rest of the UI in the
main thread. Basically any operation on a thread object in
ThreadIndexMode needs to be protected against ThreadSet#add_message (and
probably other ThreadSet methods) because add_message can remove
containers from the thread tree, leaving you with an empty thread whose
"date" method returns nil.

I look forward to having a sup-server - I plan on writing a little
android client in Scala using actors. Almost no mutable state and
absolutely no ncurses.
_______________________________________________
sup-talk mailing list
[email-masked]
http://rubyforge.org/mailman/listinfo/sup-talk