Where can I set MALLOC_PERMIT_INSANE_REQUESTS within XCODE?

Question

Created Dec ’22

Replies 3

Boosts 0

Views 1.6k

Participants 2

I am writing a scientific code in C++. I had activated Guard Dmalloc under "edit scheme" some while ago, and it had been silent.

I became suspicious, and wrote code that deliberately wrote to memory that is outside a malloced allocation, and I got no warning.

The online blogs etc have not been helpful, and are confusing, appearing to need me to set environment variables in the terminal window!

After trying all sorts of "coding crimes" to trigger Guard dmalloc, I suddenly get the message

GuardMalloc[KLiNG-62222]: Attempting excessively large memory allocation: 188800000 bytes

GuardMalloc[KLiNG-62222]: If you really wanted to allocate so much memory, launch your executable with the environment variable MALLOC_PERMIT_INSANE_REQUESTS set to any value to circumvent this check.

GuardMalloc[KLiNG-62222]: Explicitly trapping into debugger!!!

It is true: I am trying to allocate ~200 MB of memory. I have 64 GB available, so this is no crime. My questions are these;

(1) Where, within XCODE, do I set MALLOC_PERMIT_INSANE_REQUESTS? I tried going to the terminal window and entering set env MALLOC_PERMIT_INSANE_REQUESTS = 1 restarting XCODE, but no joy.

(2) Why is Guard Dmalloc only now starting to give messages? The "insane memory request" has been there for 3 years and not a squeak from Guard Dmalloc until now!

Thinking back, what I did do that was different is that I held down the option key while clicking the "run" arrow, and then clicked the "Run" button in the dialog box that appeared. That dialog box is identical to the "Edit Scheme" dialog box that I had used years ago to enable Guard Dmalloc. However, the "option->run" version has "Run" to close it; the "Edit Scheme" version has "Close".

I think that when I did "option->run" XCODE may have only then activated Guard Dmalloc. I am not sure, though.

Guard Dmalloc is now activated and works for me now when I click the "Run" arrow directly (no "option->run" needed anymore). I suppose that is good news. Now I have to find out where to set MALLOC_PERMIT_INSANE_REQUESTS = 1, plus other environment variables.

Many thanks in advance for any help.

Answer 1

DTS Engineer OP

Apple

Dec ’22

I don't know exactly what happened historically, but option+Run allows you to edit the scheme you're running under, and that allows you to turn on guard malloc. You should be able to get the same result by editing the scheme in advance and running without the option key (which, it seems, is the behavior you have now).

Guard malloc won't catch writes to random memory locations. It's generally useful for catching buffer overflow problems where your code writes off the end of a live allocation, and it's documented to be able to catch writes into a freed allocation, but that won't cause it to catch a write into a VM page that it didn't allocate.

To set environment variables in Xcode, go back to the scheme editor and choose the "Arguments" tab. There are two lists there, the first for command line arguments to pass into your main function, and the second for environment variables to set for your process. You should be able to set MALLOC_PERMIT_INSANE_REQUESTS there.

Note that environment variables are per-process. Setting them in Terminal doesn't affect an executable launched by Xcode, since Xcode is creating your app's process, not Terminal (or, more specifically, the shell process that's running in Terminal).

Answer 2

MMJT13 OP

Dec ’22

Thank you "Polyphonic" for your clear and very helpful reply. Your suggestion to use the second row, "Environment Variables" of the arguments tab worked. I never knew what those were – now I am much wiser.

At first, setting "MALLOC_PERMIT_INSANE_REQUESTS = 1", did not work. I got that from another blog where it was to be entered as a command line "set env MALLOC_PERMIT_INSANE_REQUESTS = 1". That blog implied that any value would work. In XCODE I removed the "= 1", and it then worked.

Again, thank you. You have made my day!

Answer 3

MMJT13 OP

Dec ’22

A quick follow-up. Guard malloc did, in fact, catch my test write to a memory location about 1,000,000 bytes beyond the allocated upper boundary. This is reassuring, as the normal code appears to have passed the Guard malloc test – at least for now.