nmail: [Bug] Crash after some time in the list view, with no user action
Sorry if you are hearing so much from me lately. 😮
I’ve set up my work email account and nmail manages to fetch a handful of messages (some in the Trash, and everything else is in “Deleted items” because I have a forward/delete procedure in place), but every time I try to fetch e-mails from this latter folder, nmail crashes with the following output:
unexpected termination: 13
0 0x000000000046c98d Util::SignalHandler(int)
1 0x00007ffaf650c850
2 0x00007ffaf6c6e7ef __write
3 0x00007ffaf6b17775
4 0x00007ffaf6b15674 BIO_write
5 0x00007ffaf6d6bba0 ssl3_write_pending
6 0x00007ffaf6d6c510 ssl3_write_bytes
7 0x00007ffaf6ca5cdc
8 0x00007ffaf6ca4267 mailstream_low_write
9 0x00007ffaf6ca4cc8 mailstream_flush
a 0x00007ffaf6cc3286 mailimap_uid_fetch_qresync_vanished
b 0x00007ffaf6cabde1 mailimap_uid_fetch_changedsince
c 0x000000000042e1a7 Imap::GetHeaders(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::set<unsigned int, std::less<unsigned int>, std::allocator<unsigned int> > const&, bool, bool, std::map<unsigned int, Header, std::less<unsigned int>, std::allocator<std::pair<unsigned int const, Header> > >&)
d 0x0000000000435e59 ImapManager::PerformRequest(ImapManager::Request const&, bool, bool)
e 0x0000000000437026 ImapManager::Process()
f 0x0000000000438fbe std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (ImapManager::*)(), ImapManager*> > >::_M_run()
10 0x00007ffaf68e94a0
11 0x00007ffaf6c6510e
12 0x00007ffaf65e2fff clone
Here is the log file: log.txt
It may be worth noting that there are several thousand messages in this folder. The white space in “Deleted items” does not seem to be the issue because nmail successfully fetched like 10 or 12 messages from this folder.
Note also that the account was initially set in French in OWA, with folder names translated to French. The associated accents could not be displayed properly in nmail (I had some broken syntax instead), which is why I changed the region to English in case this was causing the fetching problem, but it turned out that it was not the issue.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 49 (49 by maintainers)
Root cause analysis for those interested: The previous attempt to fix this bug was to remove the application-specific SIGPIPE signal handler. This was a mistake, because SIGPIPE defaults to application termination(!) which caused nmail to silently “crash”, leaving no hints in the logs. The
debug-mail.shlog file provided made it clear that SIGPIPE still was crashing nmail. A quickman 7 signalconfirmed that(Term stands for terminating)
After finding this I did some googling and found this post https://securityboulevard.com/2018/10/tcp-ip-sockets-and-sigpipe/ which describes the SIGPIPE issue and other potential solutions to it.
For nmail the fix is to explicitly ignore SIGPIPE signals.
In the above commit we also improve general signal handling, to enable nmail to gracefully shutdown when requested by OS signalling.
Hi @Kabouik - thanks for sharing the logs from running
./util/debug-nmail.shvia email, I believe I’ve finally found and addressed the root cause. Please reopen the issue if you still encounter the crash.