recursive deadlock when sending email #326

dmwit · 2014-09-10T07:23:04Z

Running the latest sup from git (self-reports as v0.19.0) on ruby-2.0.0p353 (2013-11-22 revision 43784), when I hit "y" to send a message, the message gets appropriately sent, then the following:

--- ThreadError from thread: main
deadlock; recursive locking
/home/dmwit/.gem/ruby/gems/sup-0.19.0/lib/sup/buffer.rb:268:in `lock'
/home/dmwit/.gem/ruby/gems/sup-0.19.0/lib/sup/buffer.rb:268:in `draw_screen'
/home/dmwit/.gem/ruby/gems/sup-0.19.0/lib/sup/buffer.rb:700:in `flash'
(eval):1:in `flash'
/home/dmwit/.gem/ruby/gems/sup-0.19.0/lib/sup/modes/edit_message_mode.rb:542:in `rescue in send_message'
/home/dmwit/.gem/ruby/gems/sup-0.19.0/lib/sup/modes/edit_message_mode.rb:522:in `send_message'
/home/dmwit/.gem/ruby/gems/sup-0.19.0/lib/sup/mode.rb:59:in `handle_input'
/home/dmwit/.gem/ruby/gems/sup-0.19.0/lib/sup/buffer.rb:222:in `handle_input'
/home/dmwit/.gem/ruby/gems/sup-0.19.0/bin/sup:268:in `<module:Redwood>'
/home/dmwit/.gem/ruby/gems/sup-0.19.0/bin/sup:74:in `<top (required)>'
/home/dmwit/bin/sup:23:in `load'
/home/dmwit/bin/sup:23:in `<main>'

I'm using msmtp to send as in this configuration:


---
:accounts:
  :default:
    :name: X
    :email: X@X.X
    :alternates:
    - X@X.X
    - X@X.X
    - X@X.X
    - X@X.X
    - X@X.X
    :sendmail: msmtp -t --read-envelope-from
    :signature: /home/X/.signature
    :gpgkey: ''
:editor: vim
:thread_by_subject: false
:edit_signature: false
:ask_for_from: false
:ask_for_to: true
:ask_for_cc: false
:ask_for_bcc: false
:ask_for_subject: true
:account_selector: false
:confirm_no_attachments: true
:confirm_top_posting: true
:jump_to_open_message: true
:discard_snippets_from_encrypted_messages: false
:load_more_threads_when_scrolling: true
:default_attachment_save_dir: ''
:sent_source: maildir:/home/X/mail/sent
:archive_sent: true
:poll_interval: 300
:wrap_width: 0
:slip_rows: 0
:col_jump: 2
:stem_language: english
:sync_back_to_maildir: false
:continuous_scroll: false
:always_edit_async: false
:time_mode: 24h

The text was updated successfully, but these errors were encountered:

dmwit · 2014-09-10T07:26:28Z

Um, correction: this is sup from gem install sup, not the latest from git. My memory failed me.

gauteh · 2014-09-10T09:54:53Z

Did this usually work and does it happen consistently? If you try to
save the message and then send it with msmtp outside of sup does it
work?

dmwit · 2014-09-12T16:15:42Z

For "usually work": I've only just recently installed sup, so I can't comment here.

I can send messages with msmtp via the command line, and it exits without error. I don't know how to save a message to send with msmtp outside of sup (and the wiki search doesn't give any hits for "save") -- can you give brief instructions on how to save a message?

dmwit · 2014-09-12T16:31:42Z

(By the way, I tried hitting 'P' to save a draft of a message. It seems to work in that sup still knows about the draft next time I start it, but there's nothing in .sup/drafts to hand off to msmtp afterwards.)

rakoo · 2014-09-12T21:47:25Z

It seems like the code is failing on this block:

    rescue SystemCallError, SendmailCommandFailed, CryptoManager::Error => e
      warn "Problem sending mail: #{e.message}"
      BufferManager.flash "Problem sending mail: #{e.message}"

Maybe e can give us more information. Unless you launched sup in error mode, by default the warn should have output the content of e.message, but it's not included in the sup-exception-log.txt. Could you please re-run sup, reproduce and paste the error ?

gauteh · 2014-09-13T08:12:55Z

Excerpts from Matthieu Rakotojaona's message of September 12, 2014 23:47:

It seems like the code is failing on this block:
    rescue SystemCallError, SendmailCommandFailed, CryptoManager::Error => e
      warn "Problem sending mail: #{e.message}"
      BufferManager.flash "Problem sending mail: #{e.message}"
Maybe e can give us more information. Unless you launched sup in error mode, by default the warn should have output the content of e.message, but it's not included in the sup-exception-log.txt. Could you please re-run sup, reproduce and paste the error ?

By setting the environment variable SUP_LOG_LEVEL=debug error
the log file will be flushed at every error message. That should help
get the exception logged before sup crashes and closes the file.

dmwit · 2014-09-13T22:12:56Z

Thanks, the higher log level was quite enlightening. Here's the output:

rye:~% SUP_LOG_LEVEL="debug" sup
[2014-09-13 15:05:24 -0700] using character set encoding "UTF-8"
[2014-09-13 15:05:24 -0700] No 'gpgme' gem detected. Install it for email encryption, decryption and signatures.
[2014-09-13 15:05:24 -0700] WARNING: DL is deprecated, please use Fiddle
[2014-09-13 15:05:24 -0700] dynamically loading setlocale() from libc.so.6
[2014-09-13 15:05:24 -0700] setting locale...
[2014-09-13 15:05:24 -0700] locking /home/dmwit/.sup/lock...
[2014-09-13 15:05:24 -0700] no draft source, auto-adding...
[2014-09-13 15:05:24 -0700] starting curses
[2014-09-13 15:05:58 -0700] stopped cursing
[2014-09-13 15:05:58 -0700] ERROR: oh crap, an exception
[2014-09-13 15:05:58 -0700] unlocking /home/dmwit/.sup/lock...
----------------------------------------------------------------
We are very sorry. It seems that an error occurred in Sup. Please
accept our sincere apologies. Please submit the contents of
/home/dmwit/.sup/exception-log.txt and a brief report of the
circumstances to https://github.com/sup-heliotrope/sup/issues so that
we might address this problem. Thank you!

Sincerely,
The Sup Developers
----------------------------------------------------------------
--- Errno::ENOENT from thread: main
No such file or directory - /home/dmwit/mail/sent
/home/dmwit/.gem/ruby/gems/sup-0.19.0/lib/sup/maildir.rb:46:in `chdir'
/home/dmwit/.gem/ruby/gems/sup-0.19.0/lib/sup/maildir.rb:46:in `store_message'
/home/dmwit/.gem/ruby/gems/sup-0.19.0/lib/sup/sent.rb:31:in `block (2 levels) in write_sent_message'
/usr/share/ruby/monitor.rb:211:in `mon_synchronize'
/home/dmwit/.gem/ruby/gems/sup-0.19.0/lib/sup/source.rb:105:in `synchronize'
/home/dmwit/.gem/ruby/gems/sup-0.19.0/lib/sup/sent.rb:30:in `block in write_sent_message'
rye:~% t .sup/exception-log.txt 
--- Errno::ENOENT from thread: main
No such file or directory - /home/dmwit/mail/sent
/home/dmwit/.gem/ruby/gems/sup-0.19.0/lib/sup/maildir.rb:46:in `chdir'
/home/dmwit/.gem/ruby/gems/sup-0.19.0/lib/sup/maildir.rb:46:in `store_message'
/home/dmwit/.gem/ruby/gems/sup-0.19.0/lib/sup/sent.rb:31:in `block (2 levels) in write_sent_message'
/usr/share/ruby/monitor.rb:211:in `mon_synchronize'
/home/dmwit/.gem/ruby/gems/sup-0.19.0/lib/sup/source.rb:105:in `synchronize'
/home/dmwit/.gem/ruby/gems/sup-0.19.0/lib/sup/sent.rb:30:in `block in write_sent_message'

It seems it was complaining because my "sent" maildir -- ~/mail/sent -- didn't exist. I thought for sure I had run mkdir to create it, but a quick ls shows it ain't so. I have created ~/mail/sent/{cur,new,tmp} and no longer get an exception.

Perhaps sup should consider creating a Maildir when it doesn't exist yet?

Additionally: sent mails now show up in my inbox. I have :archive_sent: true in .config/yaml. Should I open a separate bug?

gauteh · 2014-09-14T07:53:38Z

Excerpts from Daniel Wagner's message of September 14, 2014 0:12:

Thanks, the higher log level was quite enlightening. Here's the output:

[...]

--- Errno::ENOENT from thread: main
No such file or directory - /home/dmwit/mail/sent

[...]

Great that you figured it out!

Perhaps sup should consider creating a Maildir when it doesn't exist yet?

Sup does in general not modify the source, unless you are using maildir
syncback or one of the experimental sources like the maildir-root source (which does create maildirs if it needs to).

I think in this case it was a configuration error and the right action
would have been for sup to output a more meannigful error message on
the non-existant directory.

Additionally: sent mails now show up in my inbox. I have :archive_sent: true in .config/yaml. Should I open a separate bug?

Weird, I guess yeah. Please try a bit more thou, are these sent
messages from before or another client? Or are these the messages you
have sent using Sup? Remember that sup doesn't play to nicely with
other mail clients.

If you are getting in messages from the sent maildir as new messages in
the inbox you could try adding the sent label and archive them using
the before-add-hook.

Cheers, Gaute

gauteh · 2014-10-06T11:43:02Z

Closing. Low priority.

gauteh closed this as completed Oct 6, 2014

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

recursive deadlock when sending email #326

recursive deadlock when sending email #326

dmwit commented Sep 10, 2014

dmwit commented Sep 10, 2014

gauteh commented Sep 10, 2014

dmwit commented Sep 12, 2014

dmwit commented Sep 12, 2014

rakoo commented Sep 12, 2014

gauteh commented Sep 13, 2014

dmwit commented Sep 13, 2014

gauteh commented Sep 14, 2014

gauteh commented Oct 6, 2014

recursive deadlock when sending email #326

recursive deadlock when sending email #326

Comments

dmwit commented Sep 10, 2014

dmwit commented Sep 10, 2014

gauteh commented Sep 10, 2014

dmwit commented Sep 12, 2014

dmwit commented Sep 12, 2014

rakoo commented Sep 12, 2014

gauteh commented Sep 13, 2014

dmwit commented Sep 13, 2014

gauteh commented Sep 14, 2014

gauteh commented Oct 6, 2014