New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Xcode 7.0.1 crashes when `po someObject` in lldb #832

Closed
Konshin opened this Issue Oct 6, 2015 · 29 comments

Comments

Projects
None yet
@Konshin
Copy link

Konshin commented Oct 6, 2015

The problem of absolute is identical to this:
#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

This comment has been minimized.

Copy link
Contributor

NachoSoto commented Oct 6, 2015

See ReactiveCocoa/ReactiveCocoa#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:

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

@nvkv

This comment has been minimized.

Copy link

nvkv commented Oct 7, 2015

Yep, same to me.

@mattijsf

This comment has been minimized.

Copy link

mattijsf commented Oct 12, 2015

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

This comment has been minimized.

Copy link

mattijsf commented Oct 13, 2015

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

This comment has been minimized.

Copy link
Member

mdiep commented Oct 13, 2015

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

This comment has been minimized.

Copy link

mattijsf commented Oct 13, 2015

--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

This comment has been minimized.

Copy link

mattijsf commented Oct 14, 2015

Ah. Just like #727 The above only fixes it on my local machine. Exchanging the binary towards other team members breaks po in their Xcode.

Ugh...

@NachoSoto

This comment has been minimized.

Copy link
Contributor

NachoSoto commented Oct 27, 2015

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:
screen shot 2015-10-27 at 10 46 08

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

@ollieatkinson

This comment has been minimized.

Copy link

ollieatkinson commented Nov 12, 2015

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

@a-voronov

This comment has been minimized.

Copy link

a-voronov commented Nov 12, 2015

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 😞

@NachoSoto

This comment has been minimized.

Copy link
Contributor

NachoSoto commented Nov 12, 2015

@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

This comment has been minimized.

Copy link

a-voronov commented Nov 12, 2015

@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

This comment has been minimized.

Copy link

a-voronov commented Nov 13, 2015

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

This comment has been minimized.

Copy link
Contributor

NachoSoto commented Nov 16, 2015

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

This comment has been minimized.

Copy link
Contributor

NachoSoto commented Nov 16, 2015

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

@a-voronov

This comment has been minimized.

Copy link

a-voronov commented Nov 16, 2015

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

This comment has been minimized.

Copy link

AAverin commented Nov 23, 2015

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

This comment has been minimized.

Copy link
Contributor

NachoSoto commented Nov 23, 2015

Yes, see #924

@soffes

This comment has been minimized.

Copy link

soffes commented Nov 25, 2015

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

@NachoSoto

This comment has been minimized.

Copy link
Contributor

NachoSoto commented Nov 25, 2015

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

Until you clear derived data ;)

@drewcrawford

This comment has been minimized.

Copy link

drewcrawford commented Dec 22, 2015

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

This comment has been minimized.

Copy link

AndrewSB commented Feb 4, 2016

@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

This comment has been minimized.

Copy link
Contributor

NachoSoto commented Feb 4, 2016

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

@ramrumram

This comment has been minimized.

Copy link

ramrumram commented May 4, 2016

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 comment has been minimized.

Copy link
Member

ikesyo commented Aug 3, 2016

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

@ikesyo ikesyo closed this Aug 3, 2016

@AndrewSB

This comment has been minimized.

Copy link

AndrewSB commented Aug 4, 2016

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

On Tue, Aug 2, 2016 at 7:44 PM Syo Ikeda notifications@github.com wrote:

Closed #832 #832.


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

@werose

This comment has been minimized.

Copy link

werose commented Sep 19, 2016

same problem

@eridbardhaj

This comment has been minimized.

Copy link

eridbardhaj commented Nov 9, 2016

The problem is still present with Xcode 8.1

@AndrewSB

This comment has been minimized.

Copy link

AndrewSB commented Nov 9, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment