Re: Constantly Getting Assertion Failure
Re: Constantly Getting Assertion Failure
- Subject: Re: Constantly Getting Assertion Failure
- From: Andreas Grosam <email@hidden>
- Date: Fri, 11 Nov 2011 10:13:29 +0100
On Nov 11, 2011, at 12:33 AM, Joar Wingfors wrote:
> Hi Andreas,
>
> Please file a bug report:
>
> <http://developer.apple.com/bugreporter/>
>
> To work around the issue, have you tried to delete your per-user data from the .xcworkspace directory?
Hi Joar,
Thanks for the reply. No, I didn't try this. But any further explanation probably requires more info about my project setup (see below).
>
> Do you have an include / import statement that looks like what is suggested from the assertion failure:
>
> ../../Source/xyz/parser.h
No. This path has been constructed by Xcode, as well as other paths that has been displayed in error messages when compiling. The error description mentioned paths to source files which were obviously corrupt - and looked something like this: "../../Source/xyz/../../Source/xyz/parser.h"
The issue started as I moved a folder containing a workspace, which references a couple of projects located within subfolders, that is, all are located within this common root folder. There is a sub folder "Source" containing all the sources for a library target. Hese sources will be shared in several other projects/targets whose folder is located the common root folder, as well. E.g. projects for building an iOS static library, Mac OS X framework, static lib, dylib, examples, test cases, bench tests, etc. Each of these projects reference the "Source" folder via a corresponding Group.
In order to make it more easy to define Header Search Paths for the various targets, I defined a *Source Tree* variable, defined via Xcode preference. Say, "MY_SRC_ROOT" has been defined as "/Users/agrosam/Develop/My_Project/Source". Sources/folders/Groups were referenced relative to this "Source Tree" variable, e.g. "Header Search Paths": $(MY_SRC_ROOT).
But after moving the root folder to a different location, this *Source Tree path* has been invalidated, of course. Here, I realized that it would be a better idea to reference my Source folder now from within each project/target via a *custom build setting*. This is a path relative to the corresponding project. That is, I defined a *custom build setting* "MY_SRC_ROOT" as "$(SRCROOT)/../../Source". So moving the root folder would not cause paths to break anymore.
After I defined this custom build setting for a few project, many of the file references in projects/targets "went red" - that is, file references have been colorized in red. Since this kind of thing happens frequently, I knew already how to fix this. So, I tried to re-associate them: selecting a Group, then using the file inspector, associating this group with the corresponding file on the disk. Then, selecting one or more red file references with one group, navigating (via file inspector) to the corresponding files on the disc an clicking OK. his usually re-associates the file references, and makes them "black" again.
But this time, this failed miserably. I verified, the custom build settings defining the paths in projects were correct. Xcode also was (partly) able to reference files correctly from within Groups: when looking at the file inspector pane, everything seems correct. Nonetheless, many file references (a few within Groups and many or all within the Build phase lists) remained red. And, it did not compile, and Xcode very often popped this assertion dialog. The compile-errors were even more confusing since they mentioned totally wrong file paths.
My next attempt to fix this, is to delete and redefine all build settings that include a path to a custom build setting (a variable which defines a path), and removing all Groups from projects that reference my source folder and re-adding them, and then re-define all the compiled sources, public/private headers, and all references to linked libraries for each project. (for something like 25 targets). In other words, more or less I have to setup everything new.
That way, I managed to fix the path problem now, at least for one project.
But even after doing this, Xcode sometimes colored file references within build phase lists red, although the corresponding file references within the Group in the corresponding project were *not* red. A re-launch of Xcode fixed that, too (minor issue, but still confusing)
There is probably a bug somewhere in Xcode, when constructing a path. Xcode also seems picky when defining a custom build setting which starts with "../<path>", e.g. MY_SRCROOT = "../../Source"
It might be better to use MY_SRCROOT = "$(SRCROOT)/../../Source">, where possible. For example, it should be effectively the same when used as the root of a path somewhere in the build setting, e.g. : "Header Search Paths" = $(MY_SRCROOT)
But I can't say something more specific and there is certainly more than just an issue with defining a custom setting a la: MY_SRCROOT = "../../Source", or when deleting a "Source Tree path", or when re-associating file references.
I hope, this elaborate description may help, so I send this "as is" to the bug reporter. But please also consider the possibility, that I could have missed something important to mention. The above described "process" wasn't at all straight and clean, rather driven by trail and error, and already too late at night. ;)
Andreas
>
> If so, maybe another workaround would be to change that to simply "parser.h", and then to provide a header search path for "../../Source/xyz/". Not sure, but maybe worth a try.
>
> j o a r
>
>
> On 10 nov 2011, at 11:00, Andreas Grosam wrote:
>
>> I'm constantly getting an assertion failure in Xcode 4.2.
>> All attempts to fix this (redefining custom build settings that define a path, cleaning the build folder, re-associating file references/libraries, re-launching Xcode, etc.) failed so far.
>>
>> Any thoughts?
>>
>>
>> ASSERTION FAILURE in /SourceCache/DVTFoundation/DVTFoundation-903/Framework/Classes/FilePaths/DVTFilePath.m:370
>> Details: fsrep is relative ('../../Source/xyz/parser.h') parentPath must not be nil but it is.
>> Object: <DVTFilePath>
>> Method: +_filePathForParent:fileSystemRepresentation:length:allowCreation:
>> Thread: <NSThread: 0x40314f620>{name = (null), num = 109}
>> Hints: None
>> Backtrace:
>> 0 0x000000010abea466 -[IDEAssertionHandler handleFailureInMethod:object:fileName:lineNumber:messageFormat:arguments:] (in IDEKit)
>> 1 0x000000010a262794 _DVTAssertionFailureHandler (in DVTFoundation)
>> 2 0x000000010a1ffd32 +[DVTFilePath _filePathForParent:fileSystemRepresentation:length:allowCreation:] (in DVTFoundation)
>> 3 0x000000010a1ff963 +[DVTFilePath _filePathForParent:pathString:] (in DVTFoundation)
>> 4 0x000000010a200d47 +[DVTFilePath filePathForPathString:] (in DVTFoundation)
>> 5 0x000000010a847dee __103-[IDEIndexClangQueryProvider importedFileAtDocumentLocation:withCurrentFileContentDictionary:forIndex:]_block_invoke_0 (in IDEFoundation)
>> 6 0x000000010a1fdd56 __38-[DVTDispatchLock performLockedBlock:]_block_invoke_0 (in DVTFoundation)
>> 7 0x00007fff90063aad _dispatch_barrier_sync_f_invoke (in libdispatch.dylib)
>> 8 0x000000010a1fdcff -[DVTDispatchLock performLockedBlock:] (in DVTFoundation)
>> 9 0x000000010a8453cc -[IDEIndexClangQueryProvider performClang:] (in IDEFoundation)
>> 10 0x000000010a847c4f -[IDEIndexClangQueryProvider importedFileAtDocumentLocation:withCurrentFileContentDictionary:forIndex:] (in IDEFoundation)
>> 11 0x000000010ad5bf97 __101-[IDEIncludesGeniusResultsFinder _getUpdateGeniusResultsPhaseOneBlock:phaseTwoBlock:phaseThreeBlock:]_block_invoke_078 (in IDEKit)
>> 12 0x000000010ac4608d __51-[IDEIndexGeniusResultsFinder _updateGeniusResults]_block_invoke_0446 (in IDEKit)
>> 13 0x00007fff900618ba _dispatch_call_block_and_release (in libdispatch.dylib)
>> 14 0x00007fff9006310a _dispatch_queue_drain (in libdispatch.dylib)
>> 15 0x00007fff90062f66 _dispatch_queue_invoke (in libdispatch.dylib)
>> 16 0x00007fff90062760 _dispatch_worker_thread2 (in libdispatch.dylib)
>> 17 0x00007fff92a793da _pthread_wqthread (in libsystem_c.dylib)
>> 18 0x00007fff92a7ab85 start_wqthread (in libsystem_c.dylib)
>>
>> _______________________________________________
>> 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
>
_______________________________________________
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