Can someone spot what's going on here?
I have a long-standing app project/workspace that embeds several sub projects, which build as embedded frameworks. It all builds and runs fine as it should.
I add a new framework subproject - nothing fancy, just a small library for some UI stuff - and before I even try and link to this new framework, running my app fails at launch, with the following stack trace:
Thread 5 Queue : XBGPDQZEZ-com.devmate.kevlarValidator/INPUT (serial)
#0 0x00007fff6fd3a1f6 in __cxa_throw ()
#1 0x00007fff55f86f0f in Security::UnixError::throwMeNoLogging(int) ()
#2 0x00007fff55d32f18 in Security::safeCopyFile(char const*, unsigned int, char const*, unsigned short) ()
#3 0x00007fff55d31ce1 in Security::MDSSession::updateDataBases() ()
#4 0x00007fff55d83ff5 in Security::MDSSession::DbOpen(char const*, cssm_net_address const*, unsigned int, Security::AccessCredentials const*, void const*, long&) ()
#5 0x00007fff55d83e74 in mds_DbOpen(long, char const*, cssm_net_address const*, unsigned int, cssm_access_credentials const*, void const*, long*) ()
#6 0x00007fff55d31223 in Security::MDSClient::Directory::cdsa() const ()
#7 0x00007fff55e449a0 in Security::MDSClient::Directory::dlGetFirst(cssm_query const&, cssm_db_record_attribute_data&, cssm_data*, cssm_db_unique_record*&) ()
#8 0x00007fff55d30cec in Security::CssmClient::Table<Security::MDSClient::Common>::startQuery(Security::CssmQuery const&, bool) ()
#9 0x00007fff55d309e1 in Security::CssmClient::Table<Security::MDSClient::Common>::fetch(Security::CssmClient::Query const&, int) ()
#10 0x00007fff55d301bc in MdsComponent::MdsComponent(Security::Guid const&) ()
#11 0x00007fff55d2fdf8 in CssmManager::loadModule(Security::Guid const&, unsigned int, Security::ModuleCallback const&) ()
#12 0x00007fff55d2fb97 in CSSM_ModuleLoad ()
#13 0x00007fff55e5d3cc in cuCspStartup ()
#14 0x00007fff55efe457 in impExpImportGuessByExamination ()
#15 0x00007fff55ef6a0c in SecKeychainItemImport ()
#16 0x00007fff55ef6e1d in SecItemImport ()
#17 0x000000010019fb50 in dKq0tsxTzQyXuAqNq1eI::Kf1B39yVGeQ9AmZ2mbLqSy(NSData*) ()
#18 0x0000000100196b50 in dKq0tsxTzQyXuAqNq1eI::dKq0tsxTzQyXuAqNq1eI(NSData*, NSData*) ()
#19 0x000000010019fdf7 in dKq0tsxTzQyXuAqNq1eI::dKq0tsxTzQyXuAqNq1eI(NSData*, NSData*) ()
#20 0x00000001001f85ff in ___ZL14dTA8w84VWLIMunPK10__CFStringPKvPK32OpaqueSecTransformImplementation_block_invoke.42 ()
#21 0x00007fff55f6b9fd in CustomTransform::AttributeChanged(void const*, void const*) ()
#22 0x00007fff55f74c40 in Transform::Do(void const*, void const*) ()
#23 0x00007fff55f74ac8 in ___ZN9Transform12SetAttributeEPKvS1__block_invoke ()
#24 0x0000000100d94cae in _dispatch_call_block_and_release ()
#25 0x0000000100d8cd8f in _dispatch_client_callout ()
#26 0x0000000100da2bbb in _dispatch_queue_serial_drain ()
#27 0x0000000100d94801 in _dispatch_queue_invoke ()
#28 0x0000000100da28d3 in _dispatch_queue_serial_drain ()
#29 0x0000000100d94801 in _dispatch_queue_invoke ()
#30 0x0000000100da3fca in _dispatch_root_queue_drain_deferred_wlh ()
#31 0x0000000100da8ea3 in _dispatch_workloop_worker_thread ()
#32 0x0000000100e08fd6 in _pthread_wqthread ()
#33 0x0000000100e08bed in start_wqthread ()
Enqueued from EDLWXOYXT-SecReadStreamTransform/INPUT (Thread 3) Queue : EDLWXOYXT-SecReadStreamTransform/INPUT (serial)
#0 0x0000000100da3930 in _dispatch_queue_push ()
#1 0x00007fff55f748f5 in Transform::SetAttribute(void const*, void const*) ()
#2 0x00007fff55f733c7 in Transform::SetAttributeNoCallback(void const*, void const*) ()
#3 0x00007fff55f6c6ed in SecTransformCustomSetAttribute ()
#4 0x00007fff55f76f22 in ___ZL29StreamTransformImplementationPK10__CFStringPKvPK32OpaqueSecTransformImplementation_block_invoke.6 ()
#5 0x00007fff55f6b9aa in CustomTransform::AttributeChanged(void const*, void const*) ()
#6 0x00007fff55f74c40 in Transform::Do(void const*, void const*) ()
#7 0x00007fff55f74ac8 in ___ZN9Transform12SetAttributeEPKvS1__block_invoke ()
#8 0x0000000100d94cae in _dispatch_call_block_and_release ()
There’s a fair bit more of it, since this seems to be a long chain of queued operations queing other operations, but this includes the final one that throws some sort of silent exception, causing my app to not launch.
If I take the added framework out of my workspace, it builds and runs fine again.
I cannot see what this issue is. I don’t understand how just the presence of the subproject (without linking to it) can trigger this. The function names hint that it could be some sort of security/signing issue, but again this added project isn’t actually linked to the app, nor are its signing settings any different from any of the other embedded frameworks, which don’t cause the same issue.
Any ideas? (Xcode 9.4.1, OS 10.13.6)
On Aug 8, 2018, at 22:38 , Graham Cox <graham@...> wrote:
Are you sure it’s really failing? Historically, the security framework is known to use C++ exceptions internally for flow control. If you have an Xcode C++ exception breakpoint set, it stops, but there’s really nothing wrong. The solution is to set the exception breakpoint option for Obj-C exceptions only. (Or, you can just keep resuming execution, if you want to keep the C++ exception breakpoint for other purposes.)
Well duh.toggle quoted messageShow quoted text
Thanks Quincey, that was it. I use so little C++ myself now that I’ve honestly never seen this before.
It’s still a bit of a mystery why just the presence of the added framework in the workspace (with no linking to it) triggers it at runtime though.
On 10 Aug 2018, at 12:17 am, Quincey Morris <firstname.lastname@example.org> wrote:
On Aug 9, 2018, at 17:46 , Graham Cox <graham@...> wrote:
Yeah, I don’t know why either, but I had the same experience of it suddenly doing that with no apparent cause.