• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Sure fire way to crash Xcode
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Sure fire way to crash Xcode


  • Subject: Sure fire way to crash Xcode
  • From: Greg Hurrell <email@hidden>
  • Date: Sun, 5 Dec 2004 01:22:02 +0100

I've just spent the entire day fighting against Xcode and I believe I've found a crash that's reproducible 100% of the time. Before filing a bug report I thought I'd post a message to the list to get some feedback.

How to trigger the bug:

Short version:

Try to create a framework that includes a helper application that links against that same framework.

Long version:

1. Create a Cocoa Framework Project.

2. Create two targets: one that leaves the framework in the built products directory (where it can then be embedded in an application), and one that installs the framework into /Library/Frameworks/. (The truth is that to reproduce the bug you only need one such target, but in my own projects I have two.)

3. Create a Cocoa Application that links against the framework and will embedded inside the framework. Add the framework's project file to the application project, but do not set up any dependencies yet. Set up a shell script build phase that puts a symbolic link inside the helper application bundle so that it can find the framework that will eventually contain it.

4. Go back to the framework project and add a third target. This one is a copy of the first target. Add the application's project file to the application project, but do not set up any dependencies yet. To the third target, add the application as an item to be copied in the "Bundle resources" phase.

5. At this point there is no problem because you haven't set up any dependencies. Here is the build chain you want to set up:

(a) Build the framework, but don't embed the helper application.
(b) Build the helper application, linking against the framework you just built.
(c) Now build the framework again, but embed this time the helper application.


To set up this chain you need the following dependencies:

(a) In the framework, "Target A" and "Target B" depend on the application.
(b) The application depends on the framework's "Target C".
(c) The framework's "Target C" depends on nothing.


You can test this out and it all works perfectly. Close and re-open the project files, do cleans and builds and rebuilds. Everything works fine.

Until you quit Xcode, that is. When you relaunch it and try to open either of the two project files, Xcode will churn for two minutes beachballing and using 100% of the CPU. It will then crash. Here is a snippet of the stack trace:

501 com.apple.Xcode.DevToolsCore 0x9617343c +[PBXProject projectWithFile:errorHandler:readOnly:] + 0x5ac
502 com.apple.Xcode.DevToolsCore 0x9618552c -[PBXFileReference loadedContainer] + 0x104
503 com.apple.Xcode.DevToolsCore 0x962c0990 -[PBXContainerItemProxy remoteContainer] + 0x98
504 com.apple.Xcode.DevToolsCore 0x962c0a2c -[PBXContainerItemProxy remoteContainerItem] + 0x3c
505 com.apple.Xcode.DevToolsCore 0x962c5e6c -[PBXReferenceProxy _syncCachedValuesWithRemoteReference] + 0x24
506 com.apple.Xcode.DevToolsCore 0x962c60e8 -[PBXReferenceProxy awakeFromPListUnarchiver:] + 0x50
507 com.apple.Foundation 0x909f707c -[NSArray makeObjectsPerformSelector:withObject:] + 0x108
508 com.apple.Xcode.DevToolsCore 0x96174bb8 -[PBXPListUnarchiver decodeRootObject] + 0x33c

Imagine that repeated for 500 more stack frames.

Xcode is obviously seeing some kind of circular dependency where there is none. It's true that Project A depends to some degree on Project B, and vice versa, but there is no circularity. Two targets in Project A depend on one target in Project B, and that target in turn depends on a third target in Project A. That third target has nothing to do with the other two targets so there is no circularity, nevertheless Xcode thinks there is.

It is particularly curious that Xcode has no trouble whatsoever working with these files, and you can close them and re-open them repeatedly, but as soon as you quit Xcode you've doomed yourself. On next run it won't be able to open the files. I have spent the entire day try to revert to previous versions of the project files, rolling back changes, reapplying changes, rolling back, trying to recreate projects again and again, and I am very annoyed. A day utterly wasted and nothing productive done. In fact, I've back slided because I know have half a dozen projects that I cannot open.

Unfortunately it looks as though I will have to forget about dependencies and do this build sequence manually. Very, very, very ugly. The other workaround which might work is to forget the idea of a separate helper application with its own project file and instead roll the helper application into the framework project as a separate target. I don't want to do this either but if I have to I will.

Any comments, anyone?

Cheers,
Greg



_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Prev by Date: Re: Different versions of framework?
  • Next by Date: Running more than one executable simultaneously in single project
  • Previous by thread: Archived item: "Undefined symbols: not shown" Date: Jun 14, 2004, at 8:00 AM
  • Next by thread: Running more than one executable simultaneously in single project
  • Index(es):
    • Date
    • Thread