Re: malloc was optimized out
Re: malloc was optimized out
- Subject: Re: malloc was optimized out
- From: Dmitry Markman <email@hidden>
- Date: Mon, 04 Jul 2016 16:03:38 -0400
Hi Quincey
thanks for the answer
it’s not clear what kind of pointer was returned by the program, because
code was build with optimization, so I wasn’t able to stop there in debugger
in any attempt to do something like
size_t m = (size_t)data;
and print m out clang started to behave as expected and didn’t optimize malloc
also the following code
unsigned char *data = (unsigned char *)malloc(need_size);
if(data[0x10000] == 0) {
printf("data == NULL\n");
return 1;
} else {
printf("data != NULL\n");
}
behaves incorrectly, it should SEGV, but malloc again was optimized out and I got the same result:
data != NULL
Program ended with exit code: 0
another observation
the following code
unsigned char *data = (unsigned char *)malloc(need_size);
if(data == NULL) {
printf("data == NULL\n");
return 1;
} else {
printf("data != NULL <<<%d>>>\n", (int)data[0x100000]);
}
free(data);
didn’t SEGV and returns
data != NULL <<<0>>>
Program ended with exit code: 0
and that is clearly wrong and obviously I’m using result of the malloc call here.
> On Jul 4, 2016, at 2:55 PM, Quincey Morris <email@hidden> wrote:
>
> On Jul 4, 2016, at 11:09 , Dmitry Markman <email@hidden> wrote:
>>
>> The compiler "knows" how malloc works, and is allowed to optimize as if it never fails.
>
> I don’t know the answer, but it seems to me at least possible that it didn’t fail. It’s at least possible that it gave you an unmapped virtual allocation of the size you asked for.
>
> Under that theory, the reason for different behavior in a release build would be that it chooses to omit availability checking, perhaps because determining the amount of “real” memory is subtle and would be an unacceptable overhead. You could find out for sure by looking at the Darwin source code, I suppose.
>
> Incidentally, what pointer does it return in the release build? Does it look like a valid pointer? Can it be used as a valid pointer (e.g. for setting byte 0 of the block to something)?
>
> Also, the 48 bits of memory address space your block consumes is possibly within the range of what address space is normally available to apps. What happens if you request a much larger amount (e.g. 2 * 64 - 1)?
>
Dmitry Markman
_______________________________________________
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