Freron MailMate

Comments and changes to this ticket

• 

  benny June 6th, 2014 @ 08:07 AM

  A few questions:

  • How many messages do you have in total (just an estimate)?
  • Do you have any antivirus software installed?

  When this happens then you can make a process sample for me by using the following command in the Terminal:

  sample MailMate 5 -file ~/Desktop/sample_mailmate.txt
  

• You flagged this item as spam.
  

  Wes Carroll June 6th, 2014 @ 04:18 PM

  • Total messages available to MailMate: approximately 23,000.
    

  (Indeed one of the first things I did when I started using MailMate was to turn off the All Mail IMAP mailbox's visibility to IMAP clients. I have also turned off the visibility of the Sent Mail mailbox, instead tagging the last two months' outgoing messages "! Recently Sent". So I expect I'm dealing with a relatively small corpus.)

  • No anti-virus software installed.
    

  (Note to all hackers: please do not take undue advantage of this relevation. That wouldn't be sporting.)

  • Re: process sample: will do. Please expect it soon.

• You flagged this item as spam.
  

  Wes Carroll June 7th, 2014 @ 10:02 PM

  Process sample attached. Please let me know if multiple such samples would be helpful: happy to oblige, of course.

  • sample_mailmate.txt 87.4 KB

• You flagged this item as spam.
  

  Wes Carroll June 7th, 2014 @ 10:19 PM

  If that sample didn't help, I bet this one will. I got it by doing the following:

  1. Shut down MailMate
     
  2. Restarted computer
     
  3. Started MailMate; found Gmail account offline
     
  4. Took account online
     
  5. Saw beachball
     
  6. Immediately sampled process
     
  7. Beachball remained through entire sample

  Thank you, and good hunting!

  • sample_mailmate.txt 103.9 KB
• 

  benny June 9th, 2014 @ 12:10 PM

  The samples explain the random nature of this problem. When MailMate connects to a server (and this happens at “random” times to check for new messages) then the server provides MailMate with one or more certificates. These are checked using an Apple API, more precisely, the SecTrustEvaluate command. This check happens on the main thread of and for some reason MailMate hangs inside this function. This is not a known issue.

  Random thoughts:

  • In theory the same should happen in Apple Mail although it might not be as obvious if it's not done on the main thread.
  • This is a Gmail account. If the problem was the certificate then all Gmail users would experience this problem.
  • If this is cause by MailMate using the Apple API wrongly then all users would experience this problem.

  This leads me to thinking that maybe something is wrong with your system. Looking at the sample I can see that the hang is probably related to network access, i.e., part of the verification of the certificate involves a network connection -- and this hangs.

  Does this ring a bell somehow? Related problems in other applications?

• You flagged this item as spam.
  

  Wes Carroll June 9th, 2014 @ 08:28 PM

  Thanks, Benny. No easy answers from me, I'm afraid, but here's what info I have for you immediately:

  1. No, I'm afraid the network access issue doesn't ring a bell. I'm not seeing network issues on this machine in general; I have a reasonably strong DSL connection with a reliable Wi-Fi router. However I will be on the lookout specifically for such issues starting at once.

  2. However, I am using Google Two-Factor Authentication, and consequently am using an application-specific password for MailMate. I remember reading that the majority of MailMate users Gmail. I wonder how many also use two-factor auth? I would assume "many," but if not, that might be worth investigating. Please let me know if that suggests an avenue you'd like me to explore. In that case, please let me know what you'd like me to do or try next.

  3. Also, it's worth pointing out that I do have some trouble getting my calendars to sync, which, like this situation, could be viewed as an inability to get Google products to work well with software on an Apple machine. Certainly the "Sec" of "SecTrustEvaluate" rings a bell here as in item 2 above.

  4. Apple Mail has never exhibited this behavior, but I haven't used it in a few weeks. When MailMate hangs, I must stop using it at once; I have been using gmail.com as a backup and will start using Apple Mail as a backup instead. That should provide good data shortly.

  5. With my possibly-naive and certainly-outdated understanding of multi-threaded development, it sounds as though perhaps MailMate has a design flaw in which mail checks don't operate on their own fully-independent thread? In other words, having the UI hang on a mail check seems problematic and fixable. (i.e. I don't mind when MailMate takes its time to check mail; I only mind that it makes me wait too.) Of course, if I misunderstand the nature of the issue, please ignore this point.

• 

  benny June 9th, 2014 @ 09:26 PM

  1. No, I don't think that could be related in any way. Server certificates should not be affected by this.

  2. That might be related, but it could also be numerous other types of issues.

  3. Good idea.

  4. It's only the verification of certificates which happen on the main thread. Mainly because it might trigger a GUI to be opened (and maybe for reasons I forgot). If the Apple security functions are thread safe then I could do more of the work in the threads and only go to the main thread when opening the GUI. For your problem it would move the hangs to the threads — not really solving anything, but maybe less annoying if those hangs are not infinite.

• You flagged this item as spam.
  

  Wes Carroll June 10th, 2014 @ 02:24 AM

  RE: #4: Finite hangs in non-critical threads sounds like a much improved state of affairs to me.

  I remain happy to help find and resolve this issue however you say.

• 

  benny June 10th, 2014 @ 07:15 AM

  Do you have a secondary machine on which you can test whether or not the problem can be reproduced? (You don't need to fetch all messages to do this.) Maybe even just a secondary account on the same machine? I would be surprised if this problem was reproducible on a different machine (and maybe network), but it would be nice to know if it is.

  With respect to item number 4, I'll take a look at the code to see how much effort it would require.

• 

  benny June 10th, 2014 @ 01:57 PM

  Again, item number 4: This may be very unstable (untested), but try this revision of MailMate: http://updates.mailmate-app.com/archives/MailMate_r4312.tbz

• 

  benny June 11th, 2014 @ 02:04 PM

  Hold down ⌥ when clicking “Check Now” to fetch the latest test release (r4317). I've done further improvements to the handling of certificates.

• You flagged this item as spam.
  

  Wes Carroll June 12th, 2014 @ 05:28 AM

  Done and continuing to use / test. I'll update here when I have feedback to report. Thanks!

• You flagged this item as spam.
  

  Wes Carroll June 18th, 2014 @ 06:14 PM

  Apologies: it's taken six days for the issue to appear again. I hope that that's a good sign, but it might simply be that the issue is sporadic on my end.

  Good news, though: I believe that the triggering event happened just now and MailMate handled it in a much much improved way. Here's what I saw:

  1. Wi-fi turned off; laptop woken from sleep; Gmail account showed within MM as "unavailable": this is expected behavior.
     
  2. Wi-fi then turned on; account still unavailable. I don't know whether that's correct behavior.
     
  3. Take account offline then online. (NOTE: the fact that this was possible -- i.e. the fact that MM was responding to user input at the time -- may represent a huge improvement.)
     
  4. Account shows available for a moment, then returns to unavailable.
     
  5. Close computer (forcing sleep); Dock computer (forcing wake); Synchronize account. (Again, ability to do this at all is very encouraging.)
     
  6. Two minutes later, account appears to be online and available: all systems go.

  In short, based on the data that shows that the UI remained available during this entire escapade, I conclude that this build appears to have resolved this issue. Nice work!

  I'll let you know if I discover anything new data. For now, though, it seems that this MM is able to handle an as-yet-undiagnosed showstopper simply by becoming more threadsafe. I would expect that that's awesome because the same code will (probqbly) handle a wide variety of other issues.

  Also noteworthy: no apparent faults in the code despite being beta. Again, thanks, and again, nice work!

• 

  benny June 18th, 2014 @ 06:43 PM

  • State changed from “new” to “fixcommitted”

  Thanks, nice with some good news since it appears I've broken something (a lot) in the latest test release: #816

• You flagged this item as spam.
  

  Wes Carroll June 18th, 2014 @ 10:07 PM

  Glad to see that 4317 still looks like a champ though. :)

• 

  benny October 15th, 2014 @ 03:32 PM

  • State changed from “fixcommitted” to “fixreleased”

  [bulk edit]