Thread: clueless malloc rant 2023

Any object allocated on the heap using malloc() does not go out existence until the program quits.
Even if free() is called, the pointer (dangling pointer) cannot be used to access the object, but the object still exists but may or may not be accessible. I am not sure about OS behavior but the memory will only be reclaimed after the program quits.

In the example below, both malloc() and free() are called and the pointer goes out of scope, yet the object still exists.

Code:

void test() {
    char *c = NULL;
    c = malloc(1);
    free(c);
}

The above is mostly false; because the freed area will be re-used sometimes.

I am using a C framework but I confirm that a window allocated on the heap, still exists when the pointer goes out of scope.
I can close it successfully but it does result in some unknown exception.

I am using automatic memory management for the c project so it is hard to tell if the window was freed when the pointer goes out of scope.

The above is mostly false; because the freed area will be re-used sometimes.

Furthermore I edited a c++ project just yesterday, I called delete on a view which was allocated on the heap using new, it had no effect whatsoever, the subviews and their listeners worked fine and it did not cause any exception which is strange.

To conclude, the freed memory is retained in both examples, if not the program would have crashed right away.

I just tested the c project with manual memory management, a free call on the button (that has first been removed from the parent view) produces a SIGSEGV exception; apparently the parent view hold strongly onto the sub views;

Unfortunately this does not affect memory, but this provides quite an insight for certain real world gui apps:
1 subviews are not really removed from the parent.
2 therefore subviews cannot and must not be freed.
3 the only way to free memory is to exit the app.

The c++ project however does not produce a SIGSEGV exception, but it could prevent the subview from being freed which is why the whole thing works.

Originally Posted by upload

In the example below, both malloc() and free() are called and the pointer goes out of scope, yet the object still exists.

Code:

void test() {
    char *c = NULL;
    c = malloc(1);
    free(c);
}

The object does not exist anymore after the free() call. The memory previously used by the object still exists, of course, but it's not allocated to anything at that point (it's free, unallocated memory). Later in the program it may be allocated to a different object.

So don't rely on an object existing after calling free() on a pointer to that object. In fact, there's a type of bug called "use-after-free" which should give you a hint that a pointer to an object cannot be used after it's freed. In other words, free an object only after you know it's not used anymore (languages with automatic memory management make that a little easier since they take care of freeing the object themselves).

The "use-after-free" failing is synonymous with a dangling pointer, so the point is moot.

1 Why does delete not delete a UI object even though it was allocated on the heap (c++ project) ?
2 How do you know the object itself does not exist after free ?
3 Why is it that so many running app grow in memory and only release memory when they quit ?

I am talking about testing of real world application, not about logical explanations.
Most people do not test these things, but I like to tinker.

Originally Posted by upload

The "use-after-free" failing is synonymous with a dangling pointer, so the point is moot.

1 Why does delete not delete a UI object even though it was allocated on the heap (c++ project) ?
2 How do you know the object itself does not exist after free ?
3 Why is it that so many running app grow in memory and only release memory when they quit ?

I am talking about testing of real world application, not about logical explanations.
Most people do not test these things, but I like to tinker.

1. Since this thread is specifically about Windows UI programming, whose API is in C, there is no C++ destructor for UI objects. You could wrap part of the Windows UI API in C++ objects so that deleting a C++ object also deletes the UI object that it manages through the Windows API (taking care to delete any references to the UI object from other UI objects). There already exist cross-platform C++ UI APIs, many of which likely work that way, so it seems a bit of wasted effort to do it all over again.
2. Because the C and C++ standards say so. You have no way to portably prove that a freed object still exists since you can't use it anymore. You can't even use a pointer to it anymore either (the pointer itself becomes invalid). It's kicked the bucket. It's shuffled off its mortal coil, run down the curtain and joined the bleedin' choir invisible. This is an ex-object!
3. Many possible reasons. Could be that they don't release memory that's no longer needed. Could be they have an ever-growing cache of stuff (cache invalidation is hard). Could be they use exponential reallocations with a growth factor close to or greater than ϕ (see, e.g., math - What is the ideal growth rate for a dynamically allocated array? - Stack Overflow). Could be they just have plain ol' memory leaks.

Originally Posted by upload

new and delete (C++) - Wikipedia


Should not new be followed by delete.

Yes (if and only if the object is no longer needed). Who said otherwise?

Originally Posted by upload

btw MFC is obsolete, Microsoft recommends c#.

C# isn't really relevant here, though. This thread seems to be about the ol' Win32 UI API in C++.