1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

On Tue, 17 May 2005 14:44:41 +0200, Luc Heinrich wrote:

>   CFIndex idx, cnt;
>   char **args = *_NSGetArgv();
>   cnt = *_NSGetArgc();
>   for (idx = 1; idx < cnt - 1; idx++) {
>     if (0 == strcmp(args[idx], "-AppleLanguages")) {
>       CFIndex length = strlen(args[idx + 1]);
>       __CFAppleLanguages = malloc(length + 1);
>       memmove(__CFAppleLanguages, args[idx + 1], length + 1);
>       break;
>
> And not so surprisingly, this block is noodling with command line
> arguments. What we need to know now is WHY exactly does this strcmp
> crash.

I've investigated this a bit more, after seeing your post which was very
useful.

The problem is that before the code above loads, the ruby interpreter has
changed the arguments array to contain just the name of the program. So,
for example, if you run something like this:

$ irb arg1 arg2

argv will contain, at startup, {"irb","arg1","arg2"}, with argc=3
Assigning to $0 in ruby sets argv[0] to whatever you're set $0 to, and
sets the rest of the arguments to NULL (see set_arg0 in ruby.c).

So, by the time the CFRuntime code executes, argv looks like this:
{"irb",NULL,NULL}. Since the code doesn't check for potentially NULL
entries, it crashes.

The quick-fix is to just disable the assignment to $0 in irb.rb - the
first line of IRB.start.

I've filed a bug report with Apple, number 4121317.

Thanks,
Jonathan