#227 ✓released

crash on key import from key server

Reported by Greg | March 4th, 2014 @ 06:43 PM | in 1.2b1 (closed)

  1. paste fingerprint into Command-F
  2. click OK to import key
  3. Key imports, sheet comes down, in the background the table rows get all messed up
  4. beach ball
  5. crash

See attached crashlog.

Comments and changes to this ticket

  • steve

    steve March 4th, 2014 @ 09:32 PM

    • State changed from “new” to “invalid”
    • Tag cleared.
    • Importance changed from “” to “Low”

    Greg: could you please download and install our latest nightly build and see if the problem persists.

    If the nightly does not fix the problem, please first open a discussion on our support platform. We'll then later open a ticket.

    All the best, steve

    Disclaimer: This is a development version which has not been thoroughly tested yet, so bugs or crashes are to be expected. Thanks for helping us test this fix.

  • Greg

    Greg March 4th, 2014 @ 09:58 PM

    @steve, could you please post the hash for that build? last time you guys asked me to download a nightly build I made the same request and received no response. If you understand the importance of signing builds for your release builds, I hope you understand the same for your nightlies.

  • steve

    steve March 5th, 2014 @ 12:25 AM

    Hey Greg,

    attached you'll find the nightly signed with out teamkey. Automated signing and sha-1 fingerprints are planned but will take more time.

    Hoep this is useful for the time being.

    All the best, steve

  • Greg

    Greg March 5th, 2014 @ 01:02 AM

    Here's another crash for you, with the new build.

  • Greg

    Greg March 5th, 2014 @ 01:04 AM

    can the ticket's importance and/or state be changed? "low"/"invalid" doesn't seem appropriate for a crash...

  • steve

    steve March 5th, 2014 @ 01:24 AM

    • State changed from “invalid” to “waiting”

    Well, all this forth and back much better belongs into our support platform. We usually create a bug once the issue has been confirmed / isolated. Then we can start with a clean correctly prioritized bug.

    For me this is still not reproducible. Which fingerprint are you using to paste that produces this crash? Or does this happen with all fingerprints?

  • steve

    steve March 5th, 2014 @ 01:31 AM

    • State changed from “waiting” to “new”
    • Importance changed from “Low” to “Medium”
  • steve

    steve March 5th, 2014 @ 01:32 AM

    • Assigned user set to “Mento”
    • Milestone set to 1.2b1
  • Greg

    Greg March 5th, 2014 @ 04:53 AM

    Steve, on my system, I think any fingerprint will do it, although I'm not certain. I did a friend's and it crashed, and I did my own (by searching for hi@okturtles.com, I think), and it resulted in the crash you see there (my friend had signed my key, and I wanted to fetch that update).

  • Greg

    Greg March 5th, 2014 @ 04:54 AM

    FYI, I'm also on a machine with 8 cores... If you're testing this on a machine with say, two cores, and it's a threading problem, that could be why you're not seeing it as often as I am.

  • Greg

    Greg March 6th, 2014 @ 04:03 AM

    OK, just had a look at the crash log, and I'm pretty sure that the reason the crash is happening is because you guys are calling cocoa gui stuff on a non-main thread, and it's not the first time I'm seeing this type of crash in GPGTools. I honestly don't know why they even allow that to happen. From what I recall none of those GUI related things are thread safe, and all such calls must be done on the main thread.

    In Espionage, we avoid this problem by running all such calls (in non-main threads) inside of these macros:

    #define INMAIN(...)         [[NSOperationQueue mainQueue] addOperationWithBlock:^{ __VA_ARGS__; }]
    #define INMAINWAIT(...) do { \
        void(^aBlock)() = ^{ \
            __VA_ARGS__; \
        }; \
        if ( __unlikely([NSThread isMainThread]) ) \
            aBlock(); \
        else \
            [[NSOperationQueue mainQueue] addOperations: \
                                    [NSArray arrayWithObject:[NSBlockOperation blockOperationWithBlock:aBlock]] waitUntilFinished:YES]; \
    } while (0)

    Put async gui stuff inside of an INMAIN call, and synchronous code into an INMAINWAIT call.

    From: https://github.com/taoeffect/TECommon/blob/master/Common.h

  • Support

    Support March 12th, 2014 @ 03:54 PM

    • State changed from “new” to “fixed”

    (from [7d001f75df1f88d277fd8d0ffbe5f80633cc9c4a]) [FIX] Crash on key import from keyserver. [#227 state:fixed assigned:mento milestone:1.1.4] https://github.com/GPGTools/GPGKeychainAccess/commit/7d001f75df1f88...

  • steve

    steve March 12th, 2014 @ 04:00 PM

    Hey Greg, can you please verify the issue is fixed in the newest nightly? (signed with team key)

  • Greg

    Greg March 15th, 2014 @ 03:42 AM

    Downloaded, verified, installed, tested, worked, but don't hold your breath as this is a threading issue, and so just because it worked this time it doesn't mean it's definitely fixed. Probably safe to close this ticket (edit: ah, I see that you marked it as Fixed). I'll re-open it or create another one if I see the crash happen again.

    Thanks for (hopefully) fixing this so quickly!! ^_^

  • steve

    steve March 17th, 2014 @ 11:18 AM

    Welcome :)

    And thanks for your valid and useful input. Let's hope this indeed is fixed.

  • steve

    steve June 18th, 2015 @ 01:38 PM

    • State changed from “fixed” to “released”

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

Shared Ticket Bins

People watching this ticket