I author a program that uses a great deal of memory to the point where malloc() can fail. I have tried to report this situation to the user with a popup message using xmessage(), but xmessage() fails when memory can no longer be allocated (it apparently does nothing at all). Writing to stdout or stderr still works, but who looks at that anymore?

So I tried releasing memory with malloc_trim() and sbrk(), in the hope that xmessage() would work (the program exits after the xmessage() call and can discard all allocated memory. I just want the message to get out).

malloc_trim() and sbrk() do not help. Monitoring the process seems to be saying that the 6 GB of allocated memory is not being released back to the system, and the program exits with this much memory still allocated.

Is there some other way?

thanks

Maybe you need SEH to handle releasing the previously alocated memory by calling 'free', I'm assuming you're allocating it in smaller chunks than 6GB

SEH?

To use free() I would have to save an unbounded number of pointers returned by malloc() and free them all
(or more accurately those that had not been free()'ed already).

I am looking for a way to free the memory, just before the program calls xmessage and then exits.
malloc_trim() and sbrk() seem to be a solution but this does not work.

Or some other way to create a popup message that works when the executing program is unable to allocate memory.

The problem with xmessage is that it needs a system() call to create a sub-process:
system("xmessage ran out of memory, will exit")
and that needs malloc() to function.

If you set up your exception handlers in the right order you could possibly pop up the xmessage() after freeing all allocated memory.

Kindly re-read my last post.

Sorry, I was under the impression that every malloc()ed block should be free()ed when you were finished with it.

That is true, of course. The problem is that when malloc() fails, you generally have no record of all prior malloc() calls that have been made and not freed, and unwinding everything that has happened up to the point of failure is arbitrarily complex and pointless - the program has just failed fatally and only needs to exit with a message the user can understand.

I plan to make a malloc() wrapper that adds a prefix in front of all pointers returned to the caller by allocating extra space and returning an offset pointer. The prefix will contain a doubly-linked list of all outstanding malloc() calls that can be easily free()d in a loop. The malloc() wrapper adds a new entry to the list, and the free() wrapper links the previous to the next list entry and then free()s the memory including the prefix.

Yes, it's up to the programmer to keep track of all allocated blocks and free them cleanly on exit, otherwise you're creating a memory leak. The wrapper idea sounds interesting but possibly a little more complex than necessary, a linked list of pointers is a great idea but really won't take up much space and may not be worth allocating the extra space during every malloc(), maybe one allocation up front for the list then for every malloc() you just add the new pointer to the list. I usually find making things more complex than required is a good way to shoot yourself in the foot .. but good luck!

"Yes, it's up to the programmer to keep track of all allocated blocks and free them cleanly on exit, otherwise you're creating a memory leak."

That is what happens when the plug is not pulled in the middle of everything. Proper recovery is just adding complexity when the only thing that can be done is to exit. Exiting frees the memory anyway - there can be no memory leak.

The space for the links is allocated WITH the caller's memory:
address = malloc(request+extra).
return address+extra to the caller.

when free wrapper is called:
free(address-extra);

The code is done and working. The program can allocate memory until failure and still pop-up a message to the user, which was not possible before.

Yes, for userspace applications you're often safe but exiting doesn't free allocated memory in every case so it's better not to be complacent.

Really, what you need to be doing here is 'planning ahead.' Determine how much memory your program has to allocate, and reserve, say, 10% of that amount for contengencies. So you have, by your own agreement, "90% to play with." Program your memory allocation routines to tally how much memory has been requested, and to throw an exception if that self-imposed limit has been exceeded. So that the program can gracefully die, or do something else that is reasonable given the circumstances.

In such cases, it is also wise to relegate the actual "worker-bee" activities to a non-interactive child process (not a thread ...) that is spawned and owned by the XWindows (GUI) application, so that the GUI never has to compete for the same memory. The memory-allocations of a GUI are quite unpredictable and sometimes quite large. A memory-intensive activity should be operating in its own virtual memory space, and it should use "self-imposed limits" in the manner just described.

Maybe the process can predict how much memory will be required to successfully carry out a particular portion of its work, maybe gleaning this information by tallying a "high-water mark" from previously completed requests. So that it will not attempt to do what probably can't be done. So that it will emerge from the narrow tunnel, however narrow that tunnel may be, "grimy and covered with soot, having done much of the work but perhaps all of it, but nonetheless graciously: alive, and with its head held high."

A program can't control how much memory it has available. But it should not suffocate, regardless.

Pragmatically speaking, if you actually get to the point where malloc(n) == NULL, you are already dead. You just haven't stopped wiggling yet.