Exception: 'Couldn't posix_spawn: error 7'

[Droppix]

Hi,

bartycrouch code -p "$HOME/Dev/Projects/Project1" -l "$HOME/Dev/Projects/Project1/"
2018-03-20 20:43:16.367 bartycrouch[90434:6107769] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Couldn't posix_spawn: error 7'
*** First throw call stack:
(
0 CoreFoundation 0x00007fff3fa27fcb __exceptionPreprocess + 171
1 libobjc.A.dylib 0x00007fff666cac76 objc_exception_throw + 48
2 CoreFoundation 0x00007fff3fab99ed +[NSException raise:format:] + 205
3 Foundation 0x00007fff41c5eaf0 -[NSConcreteTask launchWithDictionary:error:] + 4486
4 bartycrouch 0x0000000103a1dce7 bartycrouch + 257255
5 bartycrouch 0x0000000103a32221 bartycrouch + 340513
6 bartycrouch 0x0000000103a31831 bartycrouch + 337969
7 bartycrouch 0x0000000103a1f53d bartycrouch + 263485
8 bartycrouch 0x0000000103a20d67 bartycrouch + 269671
9 bartycrouch 0x0000000103a24e29 bartycrouch + 286249
10 bartycrouch 0x00000001039e148a bartycrouch + 9354
11 bartycrouch 0x00000001039e11f9 bartycrouch + 8697
12 libdyld.dylib 0x00007fff672ba115 start + 1
)
libc++abi.dylib: terminating with uncaught exception of type NSException
Abort trap: 6

[Jeehut]

Hello. Unfortunately this error description doesn't help at all. Could you provide an example project where I can reproduce the error?

[Jeehut]

Closing this due to inactivity. Will reopen if more information for investigating is provided.

[miraclebg]

Same issue here - after compiling the XIBs:

Task 'Update Interfaces' took 7.129 seconds. Starting Task 'Update Code' ... 2019-05-21 11:34:29.573 bartycrouch[10219:327757] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Couldn't posix_spawn: error 7' *** First throw call stack: ( 0 CoreFoundation 0x00007fff51faee39 __exceptionPreprocess + 256 1 libobjc.A.dylib 0x00007fff7c6fb3c6 objc_exception_throw + 48 2 CoreFoundation 0x00007fff51faec6b +[NSException raise:format:] + 193 3 Foundation 0x00007fff541c0469 -[NSConcreteTask launchWithDictionary:error:] + 4437 4 bartycrouch 0x000000010102fdac $s8SwiftCLI4TaskC6launch030_19E0ACB72F1C972020BFBD69850F9J1FLLyyF + 364 5 bartycrouch 0x000000010102f949 $s8SwiftCLI4TaskC7runSyncs5Int32VyF + 25 6 bartycrouch 0x00000001010329e9 $s8SwiftCLI3run_9arguments9directoryySS_SaySSGSSSgtKFTf4xnn_n + 393 7 bartycrouch 0x000000010102ebd9 $s8SwiftCAbort trap: 6 macpro1:vipfitter-ios mkovachev$

[Jeehut]

I've reopened the issue, but could you please provide some context like:

• the version of BartyCrouch
• your BartyCrouch configuration
• your Xcode version

Also maybe you could try to reproduce this with an example and send me the project?

[sixten]

Just ran into the same issue trying this out on our project.

1. Ran bartycrouch init
2. Ran bartycrouch update
3. Made it through the process of scanning storyboards and xibs, and then failed as soon as it started the code task:

Task 'Update Interfaces' took 6.194 seconds.
Starting Task 'Update Code' ...
2019-06-11 09:08:08.525 bartycrouch[63651:4659645] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Couldn't posix_spawn: error 7'
*** First throw call stack:
(
	0   CoreFoundation                      0x00007fff31087cfd __exceptionPreprocess + 256
	1   libobjc.A.dylib                     0x00007fff5b731a17 objc_exception_throw + 48
	2   CoreFoundation                      0x00007fff31087b2f +[NSException raise:format:] + 201
	3   Foundation                          0x00007fff3327b469 -[NSConcreteTask launchWithDictionary:error:] + 4437
	4   bartycrouch                         0x000000010aa78dac $s8SwiftCLI4TaskC6launch030_19E0ACB72F1C972020BFBD69850F9J1FLLyyF + 364
	5   bartycrouch                         0x000000010aa78949 $s8SwiftCLI4TaskC7runSyncs5Int32VyF + 25
	6   bartycrouch                         0x000000010aa7b9e9 $s8SwiftCLI3run_9arguments9directoryySS_SaySSGSSSgtKFTf4xnn_n + 393
	7   bartycrouch                         0x000000010aa77bd9 $s8Swiftfish: 'bartycrouch update -v' terminated by signal SIGABRT (Abort)

This is Xcode 10.2, macOS 10.14.5, and bartycrouch 4.0.0 (freshly installed from Homebrew).

[sixten]

I decided to play with it a bit more, and try fiddling with the settings (once I found the collapsed section in the README that describes them). After changing the value of codePath from the default . to Project (the subdirectory in which 99% of the code lives), it no longer failed. The full path to that directory is /Users/sotto/Projects/<ProductName>/development/Project. I'm running the command from the parent directory (the project root).

Should I expect that verbose mode lists all of the source files that are processed? Or does it only list strings files that, after doing the code scan, it has determined need to change? The only output is one of our dozen or so strings files, and none of the code.

Also: it's not at all clear to me what the difference between codePath and localizablePath is meant to be. With codePath set to Project, and localizablePath left as ., the tool updates a bunch of strings files down in Vendor. If both are set to Project, it does not. But I'm not sure what's actually going on in terms of what the tool is doing.

[Jeehut]

It's actually recommended somewhere in the README to set all path variables something more exact than . – so if following that tip fixes this issue, we might even elaborate on that tip further more.

Regarding the verbose mode, I think after the big refactoring mostly only the error descriptions were added to be printed out additionally. It would definitely make sense to improve the verbose output for the files being processed. Feel free to open an issue on that or even provide the fix. Should be fairly easy, you can just wrap the print code in an if checking for GlobalOptions.verbose.value to be true.

Regarding the difference between codePath and localizablePath, the README states:

codePath: The directory to search for Swift code files.
localizablePath: The enclosing path containing the localized Localizable.strings files.

Sometimes those paths may differ, e.g. if you have a Sources subfolder under App where your Swift code lies and a SupportingFiles subfolder under App which contains your Localizable.strings (which is our best practice here at Jamit Labs, see our template project). Then there's no need to search anywhere else, making BartyCrouch much faster. Or what is it that you don't understand about the difference?

[sixten]

It definitely seems that if the default options cause the tool to crash, then the tip is really more like a requirement, and updating things accordingly would be a good idea. 😉

[Jeehut]

@sixten If it was crashing for everybody you would be right, but it isn't. It only happens in specific cases, I can't say how many % of users are affected, but 3 reporters doesn't sound like many people are affected, therefore I don't see how this is an issue with the default options. It's more like a bug we should fix as soon as possible. But to do that, I need to be able to reproduce it. So it would be great if you could send me a project setup where this is failing, then I can fix it.

[anton-manchenko]

I have the same issue.

[tache]

I have the same issue

[Jeehut]

Okay, seems like this affects many people. I will have a look into this shortly then, but I can't promise I'll find the issue without an example project setup where this definitely happens. I'll do my best.

[saristotelis]

Exception has to do with ARG_MAX. If your path exceeds ARG_MAX you will get this exception.
Try moving your project to a directory similar to ~/MyProject/Path and you should be fine.

[mmcguill]

Hi, I had the same error. Just adding this as it might help narrow the problem down.

Removing my Cocoapods 'Pods' directory fixed this, so obviously it was choking on something in there. Unfortunately didn't have time to investigate further.

I'm not using Bartycrouch in anger just yet, was just testing if it could be useful for my project.

Would be super handy to have this work without having to specify a set of more particular paths.

[csknns]

There is a limit in the length(in bytes) for the arguments in every process spawned. This typically around 250KB. If the argument list is larger the system can not spawn the process.
BartyCrouch uses the tool extractLocStrings and passes in the argument list all the files that it needs to extract the translation keys from. This can get too large.

The problem can be solved since extractLocStrings supports passing the argument list in a plist file(-f flag, check the help) instead. So we can put all the files in a plist and pass that in the argument list.

/usr/bin/xcrun extractLocStrings
Usage: extractLocStrings [OPTION] file1.[mc] ... filen.[mc]

Options
 -f argumentsPlist        reads additional arguments from 'argumentsPlist'.
...

I have opened a PR that fixes the issue.

I dynamically detect the max arg value and use the argument plist method as fallback with the default method being that is currently used.

[podkovyrin]

I was able to come up with a temporary workaround by ignoring the variables provided from the Xcode by running bartycrouch via env -i. So my build phase script is the following

if which bartycrouch > /dev/null; then
    BTCRCH=`which bartycrouch`
    env -i $BTCRCH update -x
    env -i $BTCRCH lint -x
else
    echo "warning: BartyCrouch not installed, download it from https://github.com/Flinesoft/BartyCrouch"
fi

$ man env

 -i      Execute the utility with only those environment variables specified by name=value options.  The environment inherited by env is
             ignored completely.

[matbouil]

I have the same issue ...Do you have a fix for this ?

[Jeehut]

Hey everyone, I just released version 4.1.1 of BartyCrouch which attempts to fix this issue. Please try it out and report any issues you might run into. Should be available soon on Homebrew, or if you can't wait, just install it with Mint: mint install Flinesoft/BartyCrouch

Thanks to @csknns who did the hard work here!