Error 255 in Xcode 4.5 compiling with LLVM 4.1 - ios

I'm trying to compile my project with the latest xcode + sdk 6.0
when the building is almost done, I got this error:
2012-09-26 16:52:24.714 ibtoold[5603:b03] [MT] DVTAssertions: ASSERTION FAILURE in /SourceCache/IDEInterfaceBuilder/IDEInterfaceBuilder-2840/Framework/Document/IBDocument.m:1514
Details: Some objects didn't get the ibBeginArchivingDocument:withContext: callback. A class has probably overridden the method without calling through to super.
Object: <IBCocoaTouchDocument: 0x40072df00>
Method: -willArchiveWithContext:
Thread: <NSThread: 0x40010a260>{name = (null), num = 1}
Hints: None
Backtrace: 0 0x000000010550e44c -[DVTAssertionHandler handleFailureInMethod:object:fileName:lineNumber:messageFormat:arguments:] (in DVTFoundatio
1 0x000000010550e2a5 _DVTAssertionFailureHandler (in DVTFoundatio
2 0x0000000104b35245 -[IBDocument willArchiveWithContext:] (in IDEInterfaceBuilderKi
3 0x00000001086407d6 (in IDEInterfaceBuilderCocoaTouchIntegratio
4 0x0000000108640c3a (in IDEInterfaceBuilderCocoaTouchIntegratio
5 0x0000000104b44745 __47-[IBDocument compiledPackageWithOptions:error:]_block_invoke_0 (in IDEInterfaceBuilderKi
6 0x0000000104b5b9a1 -[IBDocument assertIfArbitrationIsScheduledDuring:] (in IDEInterfaceBuilderKi
7 0x0000000104b44710 -[IBDocument compiledPackageWithOptions:error:] (in IDEInterfaceBuilderKi
8 0x0000000104a46f90 (in ibtool
9 0x0000000104a440e8 (in ibtool
10 0x0000000104a43c5f (in ibtoold
11 0x0000000104a43b53 (in ibtoold
12 0x0000000104a50165 (in ibtoold
13 0x0000000104a43684 (in ibtoold
14 0x0000000104a448f1 (in ibtoold
15 0x0000000104a42524 (in ibtoold
16 0x000000000000000 Command /Applications/Xcode4.5SDK6.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/ibtool failed with exit code 255
Only for a XIB I'll not able to build with success...have you got the solution?
thanks!
Dario

Note: I edited this a few times as new ideas came to mind so its a bit jerky I know.
1)Look at the command line tool 'ibtool' - there is a man page - and you can try manually to translate the xib file and maybe validate it (I've not used this in years and years)
2) Other ideas (but failing those, you should burn a DTS Incident - you get 2 per year - and try to get some help from an Apple engineer):
clean your project
delete the cached data (Organizer->Projects->Derived Data tap 'Delete...'
insure that for this XIB the proper versioning is set (select XIB, 3rd Xcode tab on right, File options:
close the project
quit Xcode
reopen Xcode, then the product
try again
If this does not do it, use the DTS incident, or post on the internal Apple lists - the ones you have to login for - and maybe someone there knows of an issue
3) If you are truly desperate, make a copy of your xib file. Then start deleting objects, the easiest first, and try to build. At some point it may compile. Then re-add the other objects back.
4) If 3 does not do it, blow the xib file away, create a new one, and essentially reconstruct what you have.
EDIT: (update in comments by original poster)
5) Reboot the machine and try again.

"Clean" my project solved my problem. I'm using XCode 4.5.

The following steps work for me.
Thanks David for steps #1 to #4
Clean my project build
Delete the cached data (Organizer->Projects->Derived Data tap 'Delete...'
Close the project
Quit Xcode (I did stop at this step and tried to reopen Xcode but the error remains)
Restart my computer. (Tried to open Xcode afterwards but the same build error still happens)
Make a copy of Xcode (I put the copy at ~/Desktop)
Delete the original copy at /Applications
Put the copy of Xcode back to /Applications
Done

Related

Xcode 12 quit unexpectedly in Mac OS 10.15.4

Xcode 12 quit unexpectedly in Mac OS 10.15.4.
The document “Main.storyboard” had an issue that was found and repaired.
This may be due to an SCM operation such as merging. Please save the document to fix the issue.
Multiple resources have the same name: groupTableViewBackgroundColor.
Date/Time: 2020-09-26 08:18:54 +0530
End time: 2020-09-26 08:26:49 +0530
OS Version: Mac OS X 10.15.4 (Build 19E266)
Architecture: x86_64h
Report Version: 29
Data Source: Stackshots
Shared Cache: 0x2fb4000 01EE95E0-91B0-354A-BD0A-C761305CD75D
Command: Xcode
Path: /Applications/Xcode 12.app/Contents/MacOS/Xcode
Identifier: com.apple.dt.Xcode
Version: 12.0 (17219)
Build Version: 2
Product Build Version: 12A7209
Project Name: IDEFrameworks
Source Version: 17219000000000000
Parent: launchd [1]
PID: 2432
Event: hang
Duration: 475.00s
Duration Sampled: 1.99s (process was unresponsive for 473 seconds before sampling)
Steps: 20 (100ms sampling interval)
Hardware model: MacBookAir7,2
Active cpus: 4
Time Awake Since Boot: 5700s
Fan speed: 1234 rpm
--------------------------------------------------
Timeline format: stacks are sorted chronologically
Use -i and -heavy to re-report with count sorting
--------------------------------------------------
Heaviest stack for the main thread of the target process:
20 <truncated backtrace>
20 __psynch_mutexwait + 10 (libsystem_kernel.dylib + 12386) [0x7fff6a22a062]
*20 psynch_mtxcontinue + 0 (pthread + 9566) [0xffffff7f82d6e55e]
Process: Xcode [2432]
UUID: BEF84410-992D-3871-AD2A-C8C9AB4BD25C
Path: /Applications/Xcode 12.app/Contents/MacOS/Xcode
Architecture: x86_64
Parent: launchd [1]
UID: 501
Sudden Term: Tracked
Footprint: 490.54 MB
Start time: 2020-09-26 08:26:47 +0530
End time: 2020-09-26 08:26:48 +0530
Num samples: 20 (1-20)
CPU Time: 0.022s (52.9M cycles, 37.5M instructions, 1.41c/i)
Note: Unresponsive for 473 seconds before sampling
Note: 4 idle work queue threads omitted
I had exactly the same problem.
Good news, I found the solution!
Short story:
You need to find the Views that have tableCellGroupedBackgroundColor as their color and change it.
tip: This color was used by the tableView cells as a background color, look there first.
Long story:
After updating to Xcode 12.2 every time I opened Main.storyboard, the same message was displayed as yours.
Assuming it is a color incompatibility (tableCellGroupedBackgroundColor in our case), I opened Main.storyboard as Source Code (right click on the Main.storyboard -> Open As -> Source Code) and searched for "tableCellGroupedBackgroundColor".
I noticed that this color appeared several times in the "resources" at the end of the file, while it should appear only once.
This is probably why Xcode displays the error message.
Looking above, I noticed that the specific color was in the background color in tableView cells.
So I reopened Main.storyboard as Interface Builder (right click on the Main.storyboard -> Open As -> Interface builder-Storyboard) and changed the background color in all tableView cells to Default.
pro tip: You can delete the colors from the Source code directly, by deleting the lines that refers the colors to the Views.
That's it!
After that everything works perfectly again!
I have a similar issue with additional infos. In xCode 12, and 12.2 beta, my main storyboard appear after many minutes and I get:
The document “Main.storyboard” had 15 issues that were found and repaired.
The save popup also shows:
This may be due to an SCM operation such as merging. Please save the document to fix the issues.
The errors are of 3 types for me:
1- Multiple resources have the same name: darkTextColor.
2- Multiple resources have the same name: groupTableViewBackgroundColor.
3- Multiple resources have the same name: tableCellGroupedBackgroundColor.
It asks to save in order to repair but it does not repair at all.
There are no warning in the environment either before or after the save.
When the project finally loads, if I edit it for a while then it stops responding and I have to force xCode to quit. If I load my app in xCode 11.7 it shows instantly and work fine. If one of our users upgrades to IOS14 with the working version of the app it crashes in some views however if I compile with xCode12, even with storyboard file that I cannot open, and I publish on IOS14 the apps work well and the broken views shows up.
When I debug in xCode 12 and navigate to a broken view the app/xCode stops but no warning or error are displayed. I tried to change and remove this line in the storyboard file without success:

Swift 1.2 segmentation fault on compile of Release scheme

I've just upgraded to Swift 1.2 and when I attempt to compile the iOS application using the Release scheme I receive a "segmentation fault: 11".
0 swift 0x00000001105a9a08 llvm::sys::PrintStackTrace(__sFILE*) + 40
1 swift 0x00000001105a9ee4 SignalHandler(int) + 452
2 libsystem_platform.dylib 0x00007fff9a724f1a _sigtramp + 26
3 libsystem_platform.dylib 0x00007fff4fd6f6b0 _sigtramp + 3043272624
4 swift 0x00000001100e837a (anonymous namespace)::DCE::markControllingTerminatorsLive(swift::SILBasicBlock*) + 346
5 swift 0x00000001100e8109 (anonymous namespace)::DCE::markValueLive(swift::ValueBase*) + 201
6 swift 0x00000001100e791f (anonymous namespace)::DCE::run() + 1983
7 swift 0x000000011008f55e swift::SILPassManager::runFunctionPasses(llvm::ArrayRef<swift::SILFunctionTransform*>) + 1310
8 swift 0x000000011008ffe9 swift::SILPassManager::runOneIteration() + 633
9 swift 0x000000011008ea56 swift::runSILOptimizationPasses(swift::SILModule&) + 790
10 swift 0x000000010fe92ee7 frontend_main(llvm::ArrayRef<char const*>, char const*, void*) + 4695
11 swift 0x000000010fe91ae6 main + 1814
12 libdyld.dylib 0x00007fff995665c9 start + 1
The application compiles and runs perfectly when I use the Dev/Debug scheme.
I have narrowed the compiler issue down to a single file and a couple lines of code.
let directPhoneType = PhoneNumber.Codes.Contacts["D"]
phoneTypes = phoneTypes.filter { $0 != directPhoneType }
I've tried changing the filtering code around (using "element in", etc), but each attempt causes the segmentation fault still. There is other filtering logic throughout our application that compiles fine.
If I remove the filtering code or change it to a loop that manually filters the phone types, the Application runs fine in the Release scheme.
I've tried setting the optimization level to "Fastest, Unchecked" or "Fastest", the segmentation fault still occurs. If I set the optimization level to "None"; the project builds.
This code worked fine before Swift 1.2 in both schemes.
Anyone have any insight into what is going on here?
UPDATE: It looks like Xcode 6.3.1 has fixed my seg fault issues.
Ran into the same problem, without having code similar to yours. Turning off whole module optimization (which is off by default) solved the issue for me, meaning I'm still able to archive with fastest optimization settings.
Unfortunately we have these sorts of issues all the time. The fault is not with you and they are frustratingly difficult to track down. Usually somewhat arbitrary code changes eventually solve things.
Various superstitions we have developed include: reducing use of unowned where possible, reducing use of weak where possible, being cautious of the ?? operator, being cautious of "too much" stuff in one line (like max(min(x,y),z)), switching let to var, etc.
In your code I might try switching your let to a var, or try removing the filter and doing an old school
var resultList = [MyType]()
for type in phoneTypes {
if type != directPhoneType {
resultList.append(type)
}
}
or change PhoneNumber.Codes.Contacts["D"] to access that differently.
Good luck! Happy hunting.
I had this problem when switching to Swift 1.2 and not just for release scheme. While migrating, I had changed a recommended "as!" to "as?" thinking that it was what I wanted. That seems to have caused the problem; I went back and changed to "as!" and it worked.

Crash log partially symbolicated [duplicate]

I am trying to analyse a crash log that a customer sent me, but I cannot get it to symbolicate the system library calls. It does symbolicate calls to my own methods correctly. That does not make it very practical to analyse what goes wrong.
I have run 'symbolicatecrash -v', to see what is causing the lack of symbolication. The likely cause is this:
## /Users/baraupp/Library/Developer/Xcode/iOS DeviceSupport/6.1.3 (10B329)/Symbols/usr/lib/system/libsystem_kernel.dylib doesn't contain armv7s slice
I have checked the mentioned libraries with 'lipo', which says that they contain 'armv7' but no 'armv7s'. After searching the web, it came out that this is a difference between iPhone 4 and iPhone 5. The normal solution seems to be to plug-in an iPhone 5 device and download the libraries from there. But I don't have an iPhone 5.
Anybody knows how to solve this?
To give you an idea how the symbolication looks like:
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x3bab0350 0x3ba9f000 + 70480
1 libsystem_c.dylib 0x3ba26fb2 0x3b9f8000 + 192434
2 libsystem_c.dylib 0x3ba63366 0x3b9f8000 + 439142
3 libc++abi.dylib 0x3b00bdda 0x3b008000 + 15834
4 libc++abi.dylib 0x3b009094 0x3b008000 + 4244
5 libobjc.A.dylib 0x3b5bca58 0x3b5b4000 + 35416
6 libc++abi.dylib 0x3b009118 0x3b008000 + 4376
7 libc++abi.dylib 0x3b0091b0 0x3b008000 + 4528
8 libc++abi.dylib 0x3b00a626 0x3b008000 + 9766
9 libobjc.A.dylib 0x3b5bc9b0 0x3b5b4000 + 35248
10 CoreFoundation 0x3380829c 0x337ff000 + 37532
11 CoreFoundation 0x338080c4 0x337ff000 + 37060
12 GraphicsServices 0x373e7336 0x373e2000 + 21302
13 UIKit 0x357242b4 0x356cd000 + 357044
14 Flyskyhy 0x000f8a66 main (main.m:17)
15 Flyskyhy 0x000f8a1c 0xf6000 + 10780
There are only two ways to solve this:
You either need an iPhone 5 device with iOS 6.1.3 to plug into your computer so Xcode can import the symbols
Or you need to get the symbols from another developer and replace yours with them.
Usually the symbols are part of the latest Xcode release, but Apple doesn't always provide Xcode updates when an iOS version only contains bug-fixes but no API changes.
I ran into this issue as well with an iOS7 app using XCode5, even though I had all the correct symbols.
What I found was that I had taken my dSYM file out of the archive where spotlight could index it, but the crashlog was only getting partically symbolicated (as seen in the question). But I had left the actual .app file in an xcarchive, and it was not able to be indexed by spotlight. As soon as I copied that file out of the archive to the visible location, I was able to symbolicate properly.
In following answer of Kerni:
You can install related Xcode with your target version of iOS and copy ~/Library/Developer/Xcode/iOS DeviceSupport/

crash log does not symbolicate system libraries armv7s

I am trying to analyse a crash log that a customer sent me, but I cannot get it to symbolicate the system library calls. It does symbolicate calls to my own methods correctly. That does not make it very practical to analyse what goes wrong.
I have run 'symbolicatecrash -v', to see what is causing the lack of symbolication. The likely cause is this:
## /Users/baraupp/Library/Developer/Xcode/iOS DeviceSupport/6.1.3 (10B329)/Symbols/usr/lib/system/libsystem_kernel.dylib doesn't contain armv7s slice
I have checked the mentioned libraries with 'lipo', which says that they contain 'armv7' but no 'armv7s'. After searching the web, it came out that this is a difference between iPhone 4 and iPhone 5. The normal solution seems to be to plug-in an iPhone 5 device and download the libraries from there. But I don't have an iPhone 5.
Anybody knows how to solve this?
To give you an idea how the symbolication looks like:
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x3bab0350 0x3ba9f000 + 70480
1 libsystem_c.dylib 0x3ba26fb2 0x3b9f8000 + 192434
2 libsystem_c.dylib 0x3ba63366 0x3b9f8000 + 439142
3 libc++abi.dylib 0x3b00bdda 0x3b008000 + 15834
4 libc++abi.dylib 0x3b009094 0x3b008000 + 4244
5 libobjc.A.dylib 0x3b5bca58 0x3b5b4000 + 35416
6 libc++abi.dylib 0x3b009118 0x3b008000 + 4376
7 libc++abi.dylib 0x3b0091b0 0x3b008000 + 4528
8 libc++abi.dylib 0x3b00a626 0x3b008000 + 9766
9 libobjc.A.dylib 0x3b5bc9b0 0x3b5b4000 + 35248
10 CoreFoundation 0x3380829c 0x337ff000 + 37532
11 CoreFoundation 0x338080c4 0x337ff000 + 37060
12 GraphicsServices 0x373e7336 0x373e2000 + 21302
13 UIKit 0x357242b4 0x356cd000 + 357044
14 Flyskyhy 0x000f8a66 main (main.m:17)
15 Flyskyhy 0x000f8a1c 0xf6000 + 10780
There are only two ways to solve this:
You either need an iPhone 5 device with iOS 6.1.3 to plug into your computer so Xcode can import the symbols
Or you need to get the symbols from another developer and replace yours with them.
Usually the symbols are part of the latest Xcode release, but Apple doesn't always provide Xcode updates when an iOS version only contains bug-fixes but no API changes.
I ran into this issue as well with an iOS7 app using XCode5, even though I had all the correct symbols.
What I found was that I had taken my dSYM file out of the archive where spotlight could index it, but the crashlog was only getting partically symbolicated (as seen in the question). But I had left the actual .app file in an xcarchive, and it was not able to be indexed by spotlight. As soon as I copied that file out of the archive to the visible location, I was able to symbolicate properly.
In following answer of Kerni:
You can install related Xcode with your target version of iOS and copy ~/Library/Developer/Xcode/iOS DeviceSupport/

build settings to generate proper dSYM

I have a question regarding dSYM. I made an experiment with my app and added following code to it:
if (currentMenuPage_ == MenuPageAttrsVals) {
return ((ValueAndId *) [currentValues_ objectAtIndex:-1]).name;
}
as expected application crashed and crash log was generated.
However Xcode and atos can not tell me exact line where the crash is.
2 CoreFoundation 0x3192c23d -[__NSArrayI objectAtIndex:] + 165
3 MyApp 0x00053487 0x49000 + 42119
4 MyApp 0x0005102d 0x49000 + 32813
Do I have to set some special settings when building my app to generate proper dSYM?
If I call dwarfdump --uuid MyApp.app.dSYM I get a number. Does this number should appear somewhere in my crash log?
That number should appear in the first line under the Binary Images section. (It might be formatted differently, e.g. lowercase and without the - chars).
Please remember, every time you do a build, this UUID changes, and if you did not save the previous dSYM, it won't symbolicate it.
If you did not change a lot (any) code, you could replace the UUID string in the Binary Images section (keep the format in there) with the new one from the latest dSYM.
If symbolication did not work, and the UUID is correct, that folder is most likely not indexed by Spotlight, so the symbolication script can't find the dSYM.

Resources