you’re right our problem isn’t clang malloc optimization
(after list’s discussion I checked carefully release build generated code (assembler) and _malloc call was there). it looks like it’s more related to memory overcommitment unfortunately we didn’t see any dialog you described, application just crashed what was confusing that debug build isn’t failing, only release build of our library crashes application linux/windows aren’t failing for either build (on the comparable hardware) no complain, though just FYI we’re using clang from Xcode 7.2.1 toolchain, g++ 4.9.2 and VS2013 for Mac OS X, linux and windows respectively thanks > On Jul 4, 2016, at 11:21 PM, David Duncan <david.dun...@apple.com> wrote: > > >> On Jul 4, 2016, at 7:11 PM, Dmitry Markman <dmark...@mac.com >> <mailto:dmark...@mac.com>> wrote: >> >> Hi Jens >> >> I think your explanation makes sense, thank you very much >> >> I’m asking for 0x1000000000000 or 281474976710656B which is ~250TB on my >> MacBook Pro with 1TB SSD and 16GB RAM and for release build it doesn’t >> return NULL > > I can’t reproduce this. If I ask for 256TB I immediately get back NULL and a > malloc error. I tried your formulation on macOS Sierra and got back NULL. > > You probably need to further specify your particular case (that is what tools > you are building with). > >> in our case, customer is trying to build huge simulink model and we’d like >> to error out at the very early stage (allocation) >> >> and notify customer that it’s not possible to create such a model. >> >> and in our real case we trying to allocate about 10 chunks of memory 200GB >> each, so it’s far less than in my example > > malloc() should only fail on macOS if you run out of VM space, and a simple > test app will show that this occurs at around 128TB. At this point malloc() > returns NULL and reports error 3. > > Now actually trying to use that memory may cause the process attempting to do > so to be halted if there isn’t enough system memory + swap to sustain that > requirement. If the OS cannot provide more physical memory, then it will halt > some set of processes and present the user with a dialog to allow them to > recover. This is at least the behavior on recent systems (at least as of > 10.10). > > Given your statement that you are basically just doing allocations without > showing a corresponding free(), it seems unlikely that the compiler would > actually optimize this away. In particular it is exceedingly unlikely that > the compiler would optimize a malloc/free pair across a function boundary. > > My suspicion is that you actually have an issue in the intermediate layer > that you mentioned, but as you haven’t presented the precise case it is hard > to speculate further. > > -- > David Duncan > Dmitry Markman
_______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list (Xcode-users@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com This email sent to arch...@mail-archive.com
