Archive of RubyForge sup-talk mailing list
 help / color / mirror / Atom feed
From: Ben Gamari <bgamari.foss@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Fwd: Re: Crash while in thread-view-mode
Date: Tue, 13 Oct 2009 16:18:44 -0400	[thread overview]
Message-ID: <1255464686-sup-4163@ben-laptop> (raw)
In-Reply-To: <1255292742-sup-3957@masanjin.net>

Excerpts from William Morgan's message of Sun Oct 11 16:28:48 -0400 2009:
> I'm sorry you've had to rebuild the index so many times. The Xapian side
> of things is very new, and I think you've had a run of bad luck. But I
> am personally not motivated to improve index time performance, because
> that's not a common event. At least, it shouldn't be.

Unfortunately, it seems that the crashes have returned (In fact, they
returned only hours after I rebuilt). Interestingly, it is once again my
LKML label that is the culprit.

On the note of crashing, is it really necessary for the "wrong id called
on nil" exception to be fatal? Couldn't the client at least make some
attempt at recovering (skipping the problematic thread while catching
and logging the exception)? It seems like these issues could be rather
tricky to sort out (I've put an hour or so into tracking down the source
of the nils to no avail), and with a dynamically typed language like
Ruby, could occur at any time. Considering this, it seems like it might
be a good idea to handle these failures a bit more gracefully. Would
this be problematic?

Regardless, it might be a good idea to have a hierarchy of exception
classes instead of just throwing Strings. It seems that throwing
specialized classes would make the above substantially easier.

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/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:134: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:245
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk


      parent reply	other threads:[~2009-10-13 20:27 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-07 22:42 Ben Gamari
2009-10-11 20:28 ` William Morgan
2009-10-11 21:04   ` Ben Gamari
2009-10-13 20:18   ` Ben Gamari [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1255464686-sup-4163@ben-laptop \
    --to=bgamari.foss@gmail.com \
    --cc=sup-talk@rubyforge.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox