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 --- 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
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 --- 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'' /usr/lib64/ruby/1.8/rubygems/custom_require.rb:31: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/label-search-results-mode.rb:33: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 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 >
Excerpts from Ben Gamari''s message of Tue Oct 06 11:53:18 -0400 2009:> 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. >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
> 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.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...
Excerpts from Ben Gamari''s message of Tue Oct 06 12:15:46 -0400 2009:> Excerpts from Ben Gamari''s message of Tue Oct 06 11:53:18 -0400 2009: > > 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. > > > > 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!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. 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. 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.
On Wed, Oct 7, 2009 at 8:44 AM, Rich Lane <rlane at club.cc.cmu.edu> 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. -- Guillaume
On Wed, Oct 7, 2009 at 10:48 AM, Guillaume Quintard <guillaume.quintard at gmail.com> wrote:> That "solves" the problem for me.Scratch that, I just relaunched sup, and I still get the wrong id called on nil error. -- Guillaume
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
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 <wmorgan-sup at masanjin.net>
Excerpts from William Morgan''s message of Thu Oct 15 14:46:51 +0200 2009:> 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 } > endMan, I love you, I can finally use sup again. (and I love the Python comment, even if I have no effing idea of what the code could mean.) Thanks! -- Guillaume
Excerpts from William Morgan''s message of Thu Oct 15 08:46:51 -0400 2009:> 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: >Yep, this fixes it. Thank you so much. Now to sort through my backlog of mail. Thanks again, - Ben
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 <wmorgan-sup at masanjin.net>