I'm getting 4 errors for malformed JSON and one command compileSwift failed with a nonzero exit code error.
I have no clue how to debug this since it doesn't list what file this is occurring in.
I have tried deleting the workspace and pods directory and doing a new pod install && pod update.
I have tried deleting the derived data.
Neither have worked.
I was getting the same error and after reading above comments i went through my code and saw this "return 93à"
So after removing this "à" it's working fine now.
So here is my story on the exact same issue but a totally different cause and resolution.
TL;DR - Decode that problematic array as a string and read it, that is your real issue, not the one with JSON.
And here is my full story ...
First things first ... I got to this error by moving my app files to a framework project and changing their target.
I tried all you guys suggested, but with no luck, it just took me some time to find out how to report those files recursively. If anyone wants to check their encoding in the whole project, here is how to do that:
find . -type f -name "*.swift" -exec file {} +
All my files reported either ASCII and UTF-8, I even removed all Unicode characters to make them all ASCII, and it still didn't help.
Anyway, totally desperate, I decided on the last attempt ... trying to decode whatever was in that undecodable sequence of bytes.
I opened up my browser console, and did this:
String.fromCharCode(...[123, 10, 32, 32, 34, <the rest of the error array from XCode>])
And it saved my day, giving away the actual problem information.
What I got was the actual error message that for some reason (still unknown to me) the compiler wasn't able to process.
Here is a short extract from which you can also see why all people see the same sequence at the beginning:
{
"kind": "finished",
"name": "compile",
"pid": 27181,
"output": ...
... /RecognizedSymbolBlock.swift:5:15: error: use of undeclared type 'CGRect'\n let rect: CGRect;\n ...
... /RecognizedTextBlock.swift:3:7: error: type 'RecognizedTextBlock' does not conform to protocol 'Decodable'\nclass RecognizedTextBlock ...
So it turned out my problem was not having CoreGraphics framework included in the target, as well as not having it added with import CoreGraphics in the file itself.
Strangely enough, when I looked at that file in XCode (which I didn't do before as it was all just move of a code that worked before), I suddenly got all these errors displayed clearly.
My last weird finding was after I asked myself ... "Why the hell did it work in the original target without the import CoreGraphics?"
It turned out that having this in the bridging header file automatically brought it linked frameworks with it as if they were imported in all my files (it is one of the linked frameworks I use which is using UIKit):
#import <TesseractOCR/TesseractOCR.h>
But it can be anything, really, like:
#import <UIKit/UIKit.h>
The point is if you are using the bridging header file, it may easily hide the fact that you are not being forced to write consistent code with all necessary imports.
Anyway, my primary goal is to let everyone know that their original problem is most probably something totally different and the original issue is actually encoded in that error byte array everyone is getting. Even if you face encoding problems, this byte array may tell you what is wrong with your code.
Happy fixing!
In the navigator pane, the reports tab (last one) is your go-to for these situations. You can see detailed logs of build actions and can track down from there.
I had the same errors from the question. I dragged a file from project_1 to project_2 and all of a sudden all those errors appeared inside project_2. The odd thing was the new file that I dragged in had nothing to do with the errors because they appeared in completely different files that I had previously dragged in from project_1. Those files worked fine for months and the errors didn’t appear until after I dragged in the new file.
I closed Xcode, opened it back up, and the beachball of death started spinning. Xcode was basically frozen, I had to wait about 45 minutes for it to unfreeze.
I added screenshots of the errors and steps of what I had to do to resolve this issue.
1- These were the original errors, just like the ones from the op's question. I had 151 errors:
2- After the beachball stopped spinning I started to look through all of my files. I ran into a file that was somehow corrupted and its normal code was somehow replaced with the odd code inside the middle/right pane below.
Copying and Pasting the corrupted code from the middle/right pane didn't work at all which was odd but I did a global search (cmmnd+4) for "bookmark" and 6 more files appeared that also contained the corrupted code (shown inside the left navigation pane).
"bookmark" is the first word on line 1 inside the file in the middle/right pane, that's why I choose it:
3- I c+p the 6 files from the original project back into this project (the corrupted one) and the errors went from 151 to 10 new errors. All 10 errors were Invalid UTF-8 found in source file:
4- I looked inside all 6 files and inside the commented out code at the very top of the file there was a strange symbol in place of the copyright symbol on line 6:
5- I deleted the strange symbol and everything worked again.
I don't know how those files were corrupted. I think it has something to do with dragging them in from one project to another. Probably was just a random bug. To be safe I deleted the 6 files then added them back in one by one by actually creating a fresh file inside project_2’s Xcode. Then I c+p the code from same file from project_1 back to project_2. No more dragging Swift files from project to project for me.
Very strange.
In my case this compile error was thrown because of source code encode/decode issue. Try to close Xcode and programs which work with a code simultaneously and restart Xcode
I hit the exact same error message converting a workspace from Swift 4.2 to Swift 5. Even with the same numeric sequence in the error message.
The swiftc command was dying on some unicode characters in my source file (in the copyright boilerplate at the top of my file). As suggested by t0rst, you can use the inspector to see which file the command died on.
After removing the unicode characters, the build worked. I suspect there may be some issues with the update to use UTF-8 as the default storage class.
EDIT - Just discovered that the Unicode storage on the offending file was indeed wrong. In the terminal, run file *.swift on your source files. Files with 'UTF-8 Unicode text' are fine. The file that was a problem reported as 'ISO-8859 text'. Use iconv -t UTF-8 src dst to fix the file.
In my case, I had accidentally added a shortcut to a swift file, rather than the swift file itself.
To decode the above code. Right click on browser page, click on inspect and open console tab. In console tab String.fromCharCode(123, 10, 32,23) replace with your numbers and hit enter. You will receive the exact problem in readable format.
Related
I'm using VSCode + CodeLLDB + LLDB to debug a JIT'ed language (KL), however I'm having trouble getting LLDB to recognize the source files.
This is a duplicate question to LLDB equivalent of gdb "directory" command for specifying source search path?, however it's accepted answer doesn't work for me.
LLDB seems to think every source unit is compiled to the local directory - so if I execute
kl /MyWork/someFile.kl
and this file includes /any/other/path/external.kl, LLDB will believe the file is located as /MyWork/external.kl
So far, I'm (mostly) working around this problem by using
settings set target.source-map /MyWork/ /any/other/path/
However this only seems to work for a single folder. If I tried:
settings set target.source-map /MyWork/ /any/other/path/
settings set target.source-map /MyWork/ /I/use/many/dependencies/
Then LLDB seems to not be able to find -any- files in either folder. Interestingly, when I tried this LLDB errored with accurate messages
can't find external.kl in /I/use/many/dependencies/
can't find dependencies.kl in /any/other/path/
Which are accurate messages, but seems almost as if LLDB is just looking for an excuse to error-out :).
Note - I can set breakpoints and view locals, I just can't seem to view the source code at that spot.
Anywho - is there any suggestions on how to deal with this issue? There are 3 possibilities to work with:
- Modify/work with LLDB to find the source files
- Modify CodeLLDB to modify paths between LLDB + VSCode
- Somehow convince VSCode to ignore the path given to it, and search its own folders for any file matching the name.
My suspicion is that LLDB is the right place to fix this, but I am open to any suggestions (right up to the point of linking each and every source file into a flat folder I can redirect to).
lldb only knows about source paths from what is written in the debug information. The rule in DWARF (the debug format lldb uses) is that if an include file is just given by relative path or base name then it is taken to be relative to the compilation directory. Looks like that's what is happening in your case. That sounds like a compiler bug. lldb's not going to be able to reconstruct the file hierarchy at this point.
The source maps should give you a manual way to fix this, and from the sound of it, what you are describing should work. But maybe there's something else odd in the DWARF output from kl that is confusing it. You'll need to file a bug with some example binary to http://bugreporter.apple.com.
I'm trying to convert a program from S5 to S7. I've taken a look into the tutorials and documents that are available. But I cant seem to find any information about this problem:
The program is pretty complicated and I should need the XR.INI file to convert it with the S5 Converter program that came with Simatic S7. When I open the folder with the project I see all the files I need and that are described in the tutorial made by Siemens.
.ST.S5D
.XR.INI
.Z0.SEQ
I start the converter and open .ST.S5D. When I did this I get the error there is no .XR.INI file. But I can see it in the folder. Its called CERMST.INI. So I guess the name isnt correct?
In PG2000 I remade the XRF with CTRL Q but nothing changed. I also tried to rename the file to CERM.XR.INI because I saw somewhere these files can only be 6 characters long (not sure if this is true).
I tried first without the XRF. There were some errors because of the ASM command. In the tutorial I saw the converter cant handle these so I removed these functions from the program to rewrite manually later on. After this I had an error because I had no XRF. Error was:
Error No PLC type description found for called or addressed block
So I really need the .XR.INI file but the program can't find it, but its clearly in the folder. How can I fix this? How can I make a new .INI file?
Link to tutorial: http://www.sankotek.com/TR/Dokumanlar/STEP%207%20-%20From%20S5%20to%20S7.pdf
Thanks in advance!
Siemens S5 file extensions used also last two letters before file extension to mark file type, like xxxxxxXX.XXX where x is file name and X is file type for S5, without second dot in the middle like you have. File name length limit exists, I think it comes from DOS or some older operating system file length limit.
If you don't have XRF file then if i remember correctly compiler does not have compile order. Some blocks have not been compiled but are referenced in caller block that the compiler tries to compile. Compiler does not find called block in compiled blocks folder and wham... fatal error. When i had such troubles i compiled called blocks independenly before calling blocks. So you can do without XRF file. But try to include Z0.SEQ, that file has assignment list so you get nice variable names instead of just variable address numbers.
Also, stackoverflow is not the correct place to ask questions about Siemens S5-S7 conversion. You should post your questions in http://www.plctalk.net, they have guys there who used to program S5 plc-s.
i just replaced the database file from desktop to project folder and then i got this error. this error is happening in sqlite file which is blocked/uneditable so there is no chance of unintentional keyboard hit.. i have completed app,was just testing. i guess its an issue with simulator so i cleaned,erased applications from iPhone simulator folder but nothing worked.. any quick advice? below is full error message
/Volumes/Xcode/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.0.sdk/usr/include/sqlite3.h:147:12: Expected identifier or '('
other warnings along with this error are
Video_Search_Engine/favoriteListVC.m:9:9: In file included from Video_Search_Engine/Video_Search_Engine/../favoriteListVC.m:9:
Video_Search_Engine/favoriteListVC.h:10:9: In file included from /favoriteListVC.h:10:
Video_Search_Engine/DBmanager.h:10:9: In file included from Video_Search_Engine/DBmanager.h:10:
Volumes/Xcode/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.0.sdk/usr/include/sqlite3.h:49:24: Expanded from macro 'SQLITE_EXTERN'
Check the header files and implementation files that all parentheses are matched.
One way to check is to double-click the opening parentheses and see the corresponding closing parentheses. If it matches ok, then correct. Definitely, there is a missing parentheses. Check carefully.
I made Localizable.string files and compiled my project (my source code uses NSLocalizedString macro function) but my project doesn't compile because of the Localizable.string file. If I comment all the lines in the Localizable.string file, my project compiles successfully.
As result, the problem is related with the Localizable.string files. I searched about it on Google, I found that UTF-8 files (Localizable.string) has changed to UTF-16. And though I tried this... this way didn't work, too.
===============================================================
My Localizable.string file contains:
"LOCAL_APP_GRADE" = "Basic"
"LOCAL_APP_LAST_UPDATED_DATE" =
"2011/04/20"
"LOCAL_MAIN_MENU_TITLE" = "Main Menu"
In my source code:
NSLocalizedString( #"LOCAL_MAIN_MENU_TITLE", #"" );
Error message:
Copy .strings file Error Validation failed: The data couldn't be read because it has been corrupted.
I'm assuming Xcode 4 here. Double check what it shows for the encoding on each of the Localization.string files in the file inspector. When I was having that error it was due to one of the files being read as Mac Roman instead of UTF-16. Once I changed the encoding the warning went away. What was driving me nuts at first was that the warning was only happening in Xcode 4. Xcode 3 did not give it.
You also have an issue with the formatting of your .string file. All of the lines should end in a semicolon.
"LOCAL_APP_GRADE" = "Basic";
"LOCAL_APP_LAST_UPDATED_DATE" = "2011/04/20";
"LOCAL_MAIN_MENU_TITLE" = "Main Menu";
I don't think this is the cause of the warning though. At least I've never seen a warning for it. It usually only manifests itself at runtime when LOCAL_MAIN_MENU_TITLE shows up in app instead of Main Menu. It would be nice if the build process did check for semicolons though. It's easy to miss adding one when editing the files.
Per Apple:
If you run into problems during testing and find that the functions
and macros for retrieving strings are always returning the same key
(as opposed to the translated value), run the /usr/bin/plutil tool on
your strings file. A strings file is essentially a property-list file
formatted in a special way. Running plutil with the -lint option can
uncover hidden characters or other errors that are preventing strings
from being retrieved correctly.
Fire up a console window, go into your project folder, and do:
/usr/bin/plutil -lint ja.lproj/Localizable.strings
(obviously replace the correct language folder name). This will tell you exactly where the problem is!
All of the lines in .strings file should end with a semicolon. It worked for me.
I had the same issue today after importing the localisations from Apple Notes and the cause was really subtle. The standard double quotes had been swapped with slanting double quotes.
Slanting double quote: ”
Standard double quote: "
I've been struggling with this same error, and ended up having a couple similar issues, but with different details. First off, even though it appears that Xcode's internal "builtin-copyStrings" tool should be able to handle either little-endian or big-endian UTF-16 files, it really only handles big endian. My theory is it's running some extra validation step (perhaps using the plutil command line utility) that didn't used to happen in Xcode 3, and that tool barfs on anything but big-endian UTF-16. Not entirely sure though.
The second trick is that you need to make sure your strings files are saved with no BOM (Byte Order Marker). I did some editing of my .strings files in BBEdit, which ended up saving a BOM to the file, and that also appears to make Xcode 4 have a conniption fit. Xcode itself doesn't appear to have any way to remove the BOM from the file, so this has to be done in a text editor such as BBEdit or TextWrangler which can do that for you.
With Xcode 10.1, one missing semicolon stops compilation with this error:
Localizable.strings: read failed: Couldn't parse property list because
the input data was in an invalid format
BTW, you can find out if the error is general to your file (an encoding issue) or specific to one or more lines by temporarily removing most of the file content. You can then locate the problem by incrementally adding content back in until the error returns.
Perhaps you have something like:
"Bla"="bla";;
Note the duplicate ; symbol. If you have that, it will compile properly but will fail in run time.
Related to this - take care when manually merging strings into Localizable.strings - I managed to copy/paste BOTH strings from a NSLocalizedString() macro, so that the Localizable.strings entry was in this form:
"KEY" = "STRING", #"COMMENT STRING COPIED ACROSS ALSO, IN ERROR";
The bit ,#"xxx" on building caused me to get the error:
Read failed: The data couldn't be read because it isn't in the correct
format.
In this case doing a quick search on #" helped identify the places I'd done this.
I had this problem. My fix? Add a newline at the top of the file. Bizarre but it got it working for me.
So instead of at the top of my file having this:
/* comment */
"LOCAL_APP_GRADE" = "Basic"
I had to do:
[newline]
/* comment */
"LOCAL_APP_GRADE" = "Basic"
(Can't get the formatting right - don't type 'newline', just hit return!)
Looks like this is an standard message for error reading the strings file.
In my case it was a (json force of habit) colon instead of equal sign:
"key1" = "String1";
"key2" : "String2";
"key3" = "String3";
Changed it to = and everything worked fine.
My problem was, that I've forgotten ; in one of the lines
Make sure that you have declared string in following format:
"YOUR_STRING_LABEL" = "Your message";
Note: Don't forget Quotation Marks ("), Equals Sign (=) and Semicolon (;) at end.
This may be because the translation file format is wrong. You can download a mac software called Localizable.
This is the download link: https://apps.apple.com/cn/app/localizable-翻译文件工具/id1268616588?mt=12
You only need to drag Localizable.strings file to the software. and it willtell you which line in the file may have a problem.
It is useful .It saved me a lot of time. Now I share it with you, I hope it will be helpful to you.
My Localizable.strings file has somehow been corrupted and I don't know how to restore it.
If I open it as a Plain Text File it starts with weird characters that I can't copy here.
If I leave the file be the app builds. If I make any changes either the values aren't interpreted properly or I get an error at compile time.
Localizable.strings: Conversion of string failed. The string is empty.
Command /Developer/Library/Xcode/Plug-ins/CoreBuildTasks.xcplugin/Contents/Resources/copystrings failed with exit code 1
I suspect this is an encoding problem but I don't know how it happened (maybe SVN is to blame?) nor how to solve it. Any tips will be much more appreciated.
I have issues with the same file that sound very similar to your own. What happens for me is that Xcode doesn't know the correct file formating. I often get this when rearranging the project and I remove and re-add this file to the Xcode project. When I re-add the file, its encoding gets set to something like Western Roman which can't seem to render anything other than ASCII.
Here's what I do to fix the problem:
In Xcode select the Localizable.stings file in the Groups&Files panel.
Do a Get Info on that file.
On the info panel select the General tab.
In that tab go to the File Encoding and change its value.
The last step is where the trick lies as you now have to guess the right encoding. I find that for most European languages that "Unicode (UTF-8)" works. And for Asian languages I find that "Unicode (UTF-16/32)" are the ones to try.
I just had that error because I forgot a semicolon. Took me a while to figure it out. Seems like a really ambiguous compiler error but the fix was simple.
Make sure in File-Get Info, that UTF-16 is selected. If it's set to none or UTF-8 as encoding then you need to change it. If your characters have spaces between them then you choose to "re-interpret" the file as UTF-16. If there are weird characters in the file, then you need to remove them.
Execpt the UTF-8 problem, sometimes you still have to check the content in case if there are some syntax problems.
Use the following Regular Expression to verify your text line by line, if there's any line not matched, there must be a problem.
"(.+?)"="(.+?)";
You can use the plutil command line tool. Without options or with the -lint option, it checks the syntax of the file given as argument. It will tell you more precisely where the error is.
This happens to me when there is a missing quote or something not right with the file. MOst commonly, since my language files are done by another team member, he tends to forget a quote or something. Usually XCode shows an error on that line, sometimes it does'nt and just throws "Corrupted data" error.
Double check if all your strings are properly closed in quotes
Open the file in Xcode.
Right click it in Project Navigator.
Select Open as -> ASCII Property List