Carthage: Xcode 7.0.1 crashes when `po someObject` in lldb

[Konshin]

The problem of absolute is identical to this:
https://github.com/Carthage/Carthage/issues/727
But i use Alamofire, Argo, BrightFutures, SQLite.

• set a breakpoint somewhere
• hit the breakpoint in execution and po one of your variables (or po self)
• it breaks immediately and Xcode crashes entirely

Date/Time:             2015-10-06 19:22:05.897 +0500
OS Version:            Mac OS X 10.11 (15A284)
Report Version:        11
Anonymous UUID:        B8859A2B-25D4-A012-C53E-448AEE880DD9


Time Awake Since Boot: 8900 seconds

System Integrity Protection: disabled

Crashed Thread:        16

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Thread 16 Crashed:
0   com.apple.LLDB.framework        0x0000000119b9261b swift::ModuleFile::getModule(llvm::ArrayRef<swift::Identifier>) + 443
1   com.apple.LLDB.framework        0x0000000119ba5a2b swift::ModuleFile::associateWithFileContext(swift::FileUnit*, swift::SourceLoc) + 1739
2   com.apple.LLDB.framework        0x0000000119babe5d swift::SerializedModuleLoader::loadAST(swift::ModuleDecl&, llvm::Optional<swift::SourceLoc>, std::__1::unique_ptr<llvm::MemoryBuffer, std::__1::default_delete<llvm::MemoryBuffer> >, std::__1::unique_ptr<llvm::MemoryBuffer, std::__1::default_delete<llvm::MemoryBuffer> >, bool) + 589
3   com.apple.LLDB.framework        0x0000000119bae19f swift::SerializedModuleLoader::loadModule(swift::SourceLoc, llvm::ArrayRef<std::__1::pair<swift::Identifier, swift::SourceLoc> >) + 5423
4   com.apple.LLDB.framework        0x0000000119800574 swift::ASTContext::getModule(llvm::ArrayRef<std::__1::pair<swift::Identifier, swift::SourceLoc> >) + 276
5   com.apple.LLDB.framework        0x0000000119b925d5 swift::ModuleFile::getModule(llvm::ArrayRef<swift::Identifier>) + 373
6   com.apple.LLDB.framework        0x0000000119ba5a2b swift::ModuleFile::associateWithFileContext(swift::FileUnit*, swift::SourceLoc) + 1739
7   com.apple.LLDB.framework        0x0000000119babe5d swift::SerializedModuleLoader::loadAST(swift::ModuleDecl&, llvm::Optional<swift::SourceLoc>, std::__1::unique_ptr<llvm::MemoryBuffer, std::__1::default_delete<llvm::MemoryBuffer> >, std::__1::unique_ptr<llvm::MemoryBuffer, std::__1::default_delete<llvm::MemoryBuffer> >, bool) + 589
8   com.apple.LLDB.framework        0x0000000119bae19f swift::SerializedModuleLoader::loadModule(swift::SourceLoc, llvm::ArrayRef<std::__1::pair<swift::Identifier, swift::SourceLoc> >) + 5423
9   com.apple.LLDB.framework        0x0000000119800574 swift::ASTContext::getModule(llvm::ArrayRef<std::__1::pair<swift::Identifier, swift::SourceLoc> >) + 276
10  com.apple.LLDB.framework        0x0000000119b925d5 swift::ModuleFile::getModule(llvm::ArrayRef<swift::Identifier>) + 373

carthage update helped me, but the problem returns for me, if someone else do carthage update and push it in repository. Now debugging works only in those who did carthage update.

[NachoSoto]

See https://github.com/ReactiveCocoa/ReactiveCocoa/issues/2305

Apple still doesn't realize that people actually link frameworks that aren't compiled from within the project (who knew), so lots of things have been broken as a consequence of that:

• Autocompletion (http://www.openradar.me/22596105): _supposedly fixed in Xcode 7.1_
• Printing values from the console
• Hitting breakpoints
• Linking Apple TV frameworks (http://www.openradar.me/22967941): #824
• Linking fat frameworks (22967941)

And I'm sure I'm missing more things.

[nvkv]

Yep, same to me.

[mattijsf]

Same here:
Using frameworks: Alamofire, KeychainAccess, Timepiece, protobuf-swift, Cartography, CleanroomLogger, InAppSettingsKit

Process:               Xcode [42143]
Path:                  /Applications/Xcode.app/Contents/MacOS/Xcode
Identifier:            com.apple.dt.Xcode
Version:               7.0.1 (8228)
Build Info:            IDEFrameworks-8228000000000000~5
App Item ID:           497799835
App External ID:       813434267
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           Xcode [42143]
User ID:               501

Date/Time:             2015-10-12 15:46:46.642 +0200
OS Version:            Mac OS X 10.10.5 (14F27)
Report Version:        11

Time Awake Since Boot: 290000 seconds
Time Since Wake:       25000 seconds

Crashed Thread:        27

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000000

VM Regions Near 0:
--> 
    __TEXT                 0000000103e93000-0000000103e97000 [   16K] r-x/rwx SM=COW  /Applications/Xcode.app/Contents/MacOS/Xcode

Application Specific Information:
ProductBuildVersion: 7A1001
HandleCommand(command = "p config")

Btw doing a stupid p "Hi" will also crash Xcode in the same way/

Tried:

• Full Clean in Xcode
• Remove ./Carthage/Build
• Remove ~/Library/Caches/org.carthage.CarthageKit/
• carthage update --platform iOS

The above didn't do anything.

The possible solution from https://forums.developer.apple.com/thread/20889 (setting CLANG_ENABLE_MODULE_DEBUGGING to false) also didn't work.

[mattijsf]

In my case it turned out that the problematic framework was https://github.com/kishikawakatsumi/KeychainAccess To find out:

• Create a new empty project
• Add all the frameworks from used in the project that gave issues
• (lldb) p "hi" == crash (in my case)
• Now remove each framework one-by-one (or do a 50/50 approach)
• See which framework triggered the problem. In my case it definitely was KeychainAccess.framework

Now based on this I noticed that Carthage wasn't actually building this framework during carthage update it was fetching a pre-built binary from https://github.com/kishikawakatsumi/KeychainAccess/releases (v2.2.0 in my case).

Next I modified its entry in my Cartfile to enforce carthage to perform a local build:
Replaced: github "kishikawakatsumi/KeychainAccess" == 2.2.0
With: github "kishikawakatsumi/KeychainAccess" "dc325fb"

Then:
rm -rf Carthage/Build
rm -rf Carthage/Checkouts
[sudo] rm -rf ~/Library/Caches/org.carthage.CarthageKit/
carthage update --platform iOS

Now after I started Xcode en ran the project. I was able to do a successful p "hi"

[mdiep]

Next I modified its entry in my Cartfile to enforce carthage to perform a local build:

FWIW, you can pass --no-use-binaries to force Carthage to do a local build.

[mattijsf]

--no-use-binaries Good to know. Thanks!

I have to add that after I replace the working KeychainAccess.Framework again with the pre-built one from https://github.com/kishikawakatsumi/KeychainAccess/releases (just a manual download + replace) p "hi" is broken again.

Also kishikawakatsumi responded and the pre-built binaries of KeychainAccess.Framework were build with Xcode 7.0.1. My suspect was that they might have been build with an older (beta) version of Xcode 7 / Swift 2. But that seems busted.

[mattijsf]

Ah. Just like https://github.com/Carthage/Carthage/issues/727 The above only fixes it on my local machine. Exchanging the binary towards other team members breaks po in their Xcode.

Ugh...

[NachoSoto]

Apple has being doing some work to deal with this, and supposedly Xcode 7.2 beta 1 includes a fix for this.
Note this section in the release notes, though:

It's still unclear whether we need to add those settings ourselves.

[ollieatkinson]

I still receive the bug in Xcode 7.2 beta 3. forcing a re-build does temporarily fix the problem

[a-voronov]

tried Xcode 7.2 beta 3, pointing xcode-select and rebuilding frameworks with new Xcode - nothing helps, even though I'm using project only by myself so far :disappointed:

[NachoSoto]

@a-voronov could you send a crash log, and maybe a zipped project including the frameworks? I can send that to the Apple engineer who was working on this, they were interested in hearing if it got fixed, so I'm sure it would be very useful for them.

I'm still not able to build frameworks with 7.2 due to something else so I couldn't test this myself.

[a-voronov]

@NachoSoto I'm trying to figure out which of frameworks causes this problem.
I've created empty project and run carthage update with --no-use-binaries adding frameworks one by one and now it works.
Will try to migrate built frameworks to my working project and see what happens.

[a-voronov]

And now it works, but i've experienced few crashes while trying to print self in closures.
Also I'm experiencing the same issue as described above, when it runs only on my machine.
So you need to run carthage build --no-use-binaries on different machine to be able to print object in debugger.

I'm using Xcode 7.2 beta 3, carthage version 0.10, --no-use-binaries option to build frameworks and bitcode option enabled if it helps

@NachoSoto if you still want to show sample project with this setup to Apple engineer, you can download it here with brief description in README.

Thank you for your support!

[NachoSoto]

So you need to run carthage build --no-use-binaries on different machine to be able to print object in debugger.

What do you mean by that?

[NachoSoto]

Thanks a lot for that @a-voronov. I filed a radar with the sample project: rdar://23551273.

[a-voronov]

I mean, that project with "carthage" frameworks won't be "debuggable" on other than mine machine.
So if I share my project with someone else, they would need to run carthage build --no-use-binaries on their computer so they would be able to print object data.

@NachoSoto thanks!

[AAverin]

I get this crash using AlamofireObjectMapper library - whenever breakpoint is in close that is called by the library - Xcode crashes -> https://gist.github.com/AAverin/e3d293ca168b53443773
It might be related to this issue.

[NachoSoto]

Yes, see #924

[soffes]

For me, --no-use-binaries solves this.

[NachoSoto]

For me, --no-use-binaries solves this.

Until you clear derived data ;)

[drewcrawford]

WHAT YEAR IS IT

Here's a dumb idea. This crash stack traces into FOSS Swift, right? e.g.

15  com.apple.LLDB.framework        0x0000000112600c41 swift::ASTContext::getModuleByName(llvm::StringRef) + 417

is actually just this function.

In the absence of any help from Cupertino, couldn't we just organize our own fix, ship it upstream, and wait for it to get linked into Xcode 7.3?

My neckbeard's not long enough to actually do that (especially since I don't understand if this bug needs to be solved on the side that built the framework or the side that's trying to import it) but a cursory examination suggests it isn't impossible for us to unfuck this ourselves.

[AndrewSB]

@NachoSoto is there any way to get this to work _with_ downloaded libraries? I'm using https://github.com/flovilmart/ParseKit which is a repo created just to use the FacebookSDK with Carthage.

[NachoSoto]

No, Apple needs to fix that. I recommend you dupe the radar!

[ramrumram]

Crash caused by embedding frameworks or linking libraries can be sorted by

app.xcodeproj -> right click -> show package contents -> open project.pbxproj in text editor
and search and replace the lines containing the newly added framework names.

Then add it again properly once xcode opened successfully.

[ikesyo]

This should have been fixed in Xcode 7.3, let's close this.

[AndrewSB]

Does that mean that --no-use-binaries is no longer required?

On Tue, Aug 2, 2016 at 7:44 PM Syo Ikeda [email protected] wrote:

Closed #832 https://github.com/Carthage/Carthage/issues/832.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Carthage/Carthage/issues/832#event-743207534, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ADo1dPq4pJbrthUiURdMEquV9QW8cDAKks5qb-RagaJpZM4GJzB7
.

[werose]

same problem

[eridbardhaj]

The problem is still present with Xcode 8.1

[AndrewSB]

@eridbardhaj can you show us where you saw it break for you?