Re: malloc was optimized out
Re: malloc was optimized out
- Subject: Re: malloc was optimized out
- From: Dmitry Markman <email@hidden>
- Date: Tue, 05 Jul 2016 05:51:20 +0000 (GMT)
Thanks Quincey
I wasn't precise, result of the code/program should be the same or
If we're talking about numerical calculations they should be the same with some tolerance (usually very small)
I'm not aware of any simple practical way to restore program state after SEGV
Signal handler can detect it, report some useful information (stack) and exit.
So I don't think we can really catch and handle crash in acceptable (meaning restore execution after crash) way, at least I'm not aware of it.
About clang is right or not. I gave up, but not because I think you're right and I'm wrong, it's more matter of interpretations, not definitions
That is more philosophical issue :)))
When standard says that malloc returns allocated memory and in case of failure return NULL that is exactly that
Now I think I agree with Clark that standard failed to define failure :( and therefore all my arguments are not really relevant to the case
Clark Cox and Jens Alfke gave me reasonable explanation why malloc might return not NULL even if there is no enough physical memory (disk or RAM)
It would be great to know before real memory usage whether or not that amount of memory is really available
But it looks like it's not easy answerable question
BTW: if somebody interested, if I use clang -fno-builtin flag
malloc wasn't optimized out, I think I found some interesting results (just like Jens thought)
There is some hard limit of requested memory, so if I asked less than that limit
malloc returns not NULL, but if I ask more than that malloc returns NULL
for MacBookPro 16GB/1TB and 10.11.5 it's 0x7ffe59C00000
For iMac 8GB/1TB and 10.12 it's 0x7ffe5A400000 (difference is exactly 8MB (0x800000)
Thanks
Dmitry Markman
On Jul 05, 2016, at 12:42 AM, Quincey Morris <email@hidden> wrote:
On Jul 4, 2016, at 20:55 , Dmitry Markman <
email@hidden> wrote:
Theoretically clang isn’t right … code should behave identically for debug and release build
You’re going to have to give this up. Both of these statements are false, as numerous people have tried to point out, in various more or less polite ways.
— Clang is theoretically right, because it provides conforming behavior with regard to error reporting (if there’s an error, it reports it). There is no C spec requirement regarding the implementation of error detection for malloc. Again, lack of physical memory is not necessarily an error in general, though it is to you.
— Code in general may behave differently between debug and release builds. If there were a such a requirement, optimization would be illegal in general, because it changes the timing of code execution, which makes the code behave non-identically. As others have said, in your case the difference *is* timing — the timing of when physical memory is mapped into your address space — and you won’t find any requirements about *that* in the C spec.
Getting back to your problem, your real solution is to detect, catch and handle the crash that otherwise occurs when VM mapping fails. This may be unappealing, but your app is unusual in that it routinely uses huge quantities of memory, so you’re faced with implementation choices that are harder than for the rest of us who write apps with modest memory needs.
_______________________________________________
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