Question about SDL2 memory management

I have an application which I have ported from SDL 1.2 to SDL2. The SDL 1.2 version has no memory leaks (or at least the memory used stays the same), however, the SDL2 version slowly builds up until it reaches about 1,5 times the starting memory usage and then caps. The application logic did not change.

Is there some sort of internal SDL memory manager which would do this?

Windows together with an Intel chip could stop memory behavior that is
redundant and useless after it executes for a while . It sounds like
something not being deleted like maybe some ttf text with the buffer not
being deleted. With SDL 2 being so widely tested it’s hard to believe there
would be a leak no one knows about.On Mar 25, 2014 5:33 AM, “Tomeamis” <tomas.zencak at seznam.cz> wrote:

I have an application which I have ported from SDL 1.2 to SDL2. The SDL
1.2 version has no memory leaks (or at least the memory used stays the
same), however, the SDL2 version slowly builds up until it reaches about
1,5 times the starting memory usage and then caps. The application logic
did not change.

Is there some sort of internal SDL memory manager which would do this?


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL2 shouldn’t be the cause of such behavior, but nevertheless there
could be bugs in the lib or the way the port was implemented…

You could do some memory leak detection? (disclaimer: this can be quite
a bit of work)

On Linux, one can run the app under tried-and-true Valgrind
(http://valgrind.org/docs/manual/QuickStart.html) or link in LeakTracer
via LD_PRELOAD (https://github.com/fredericgermain/LeakTracer)

On Windows, install WinDBG
(http://msdn.microsoft.com/en-us/library/windows/hardware/ff551063(v=vs.85).aspx),
attach to the process while it is running, and get some live dumps of
the heap
(http://www.codeproject.com/Articles/31382/Memory-Leak-Detection-Using-Windbg).On 3/25/2014 3:32 AM, Tomeamis wrote:

I have an application which I have ported from SDL 1.2 to SDL2. The
SDL 1.2 version has no memory leaks (or at least the memory used stays
the same), however, the SDL2 version slowly builds up until it reaches
about 1,5 times the starting memory usage and then caps. The
application logic did not change.

Is there some sort of internal SDL memory manager which would do this?


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

While I was waiting for answers I also had doubts about SDL being the cause so I overloaded new and delete to output allocation info and during the run there is a deallocation for every allocation, so no luck there. I have SDL_Texture*s in a wrapper which I have checked and the amount of textures in memory also seems constant.
I only use surfaces in one function and they are propperly freed from there. As for fonts, I only load them at the start of the program so there is no way for fonts to be the cause. The only thing I use SDL to allocate extensively are textures, which are always in a wrapper which I have checked extensively and the amount of textures in memory also seems constant.

I will try WinDBG, and if that doesn’t work out, I’m just going to install linux and use Valgrind on it. (Actually I’ve tried earlier, but got an error during installation :smiley: So I’m downloading another image to try)

Also, yes, I do use Windows with an Intel chipset.

Will post update as soon as I get the WinDBG output, though it’s evening now so it might take until tomorrow.

Andreas Schiffler wrote:> SDL2 shouldn’t be the cause of such behavior, but nevertheless there could be bugs in the lib or the way the port was implemented…

You could do some memory leak detection? (disclaimer: this can be quite a bit of work)

On Linux, one can run the app under tried-and-true Valgrind (http://valgrind.org/docs/manual/QuickStart.html (http://valgrind.org/docs/manual/QuickStart.html)) or link in LeakTracer via LD_PRELOAD (https://github.com/fredericgermain/LeakTracer (https://github.com/fredericgermain/LeakTracer))

On Windows, install WinDBG (http://msdn.microsoft.com/en-us/library/windows/hardware/ff551063(v=vs.85).aspx (http://msdn.microsoft.com/en-us/library/windows/hardware/ff551063(v=vs.85).aspx)), attach to the process while it is running, and get some live dumps of the heap (http://www.codeproject.com/Articles/31382/Memory-Leak-Detection-Using-Windbg (http://www.codeproject.com/Articles/31382/Memory-Leak-Detection-Using-Windbg)).

On 3/25/2014 3:32 AM, Tomeamis wrote:

I have an application which I have ported from SDL 1.2 to SDL2. The SDL 1.2 version has no memory leaks (or at least the memory used stays the same), however, the SDL2 version slowly builds up until it reaches about 1,5 times the starting memory usage and then caps. The application logic did not change.

Is there some sort of internal SDL memory manager which would do this?


SDL mailing list
SDL at lists.libsdl.org (SDL at lists.libsdl.org)
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org (http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org)

If you don’t find any specific culprit, I would chalk it up to Windows’
memory management. I’ve seen similar cases of programs gaining memory
usage that seems inordinate and then hitting a limit where they don’t gain
any more. I presume the OS is managing when memory blocks are freed or
reused.

Jonny D

Run something like valgrind to ensure you are not leaking memory, do
not rely on the usage the OS is reporting unless it is really
inflating rapidly.On Tue, Mar 25, 2014 at 3:38 PM, Jonathan Dearborn wrote:

If you don’t find any specific culprit, I would chalk it up to Windows’
memory management. I’ve seen similar cases of programs gaining memory usage
that seems inordinate and then hitting a limit where they don’t gain any
more. I presume the OS is managing when memory blocks are freed or reused.

Jonny D


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

It’s increasing at a few hundred kB/s. The SDL1.2 version was rock solid though. Anyways, I’ll get to work with WinDBG.

Andre D wrote:> Run something like valgrind to ensure you are not leaking memory, do

not rely on the usage the OS is reporting unless it is really
inflating rapidly.

On Tue, Mar 25, 2014 at 3:38 PM, Jonathan Dearborn wrote:

If you don’t find any specific culprit, I would chalk it up to Windows’
memory management. I’ve seen similar cases of programs gaining memory usage
that seems inordinate and then hitting a limit where they don’t gain any
more. I presume the OS is managing when memory blocks are freed or reused.

Jonny D


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

R Manard wrote:

Windows together with an Intel chip could stop memory behavior that is redundant and useless after it executes for a while .

This is, to the best of my knowledge, complete rubbish.

“I overloaded new and delete to output allocation info”

SDL does not use the new and delete operators, it uses SDL_malloc and SDL_free. By default, these map to the C library’s malloc() and free() functions.------------------------
Nate Fries

Nathaniel J Fries wrote:

“I overloaded new and delete to output allocation info”

SDL does not use the new and delete operators, it uses SDL_malloc and SDL_free. By default, these map to the C library’s malloc() and free() functions.

Yes, that’s precisely why I’m worried that the memory increase is courtesy of SDL. My app uses new and delete so all heap allocations by my app should be logged by the overloaded operators.

Also, I have finally managed linux so I’m going to post valgrind results in the evening. WinDBG apparently needs a PDB file which is not produced by GCC (my compiler of choice) and VC++ doesn’t support all the C++11 features I need so WinDBG is out. Although the heap reports I’ve gathered with just system library symbols from Microsoft’s servers, the heaps are stable. The numbers were far too low though (half a kilobyte), so I wrote them off as more or less bogus.

Shortly after I posted my message above I received a message from R Manard with the following:
"> ----- Original Message -----

Subject: Latrice has a small penis
Date: Wed, 26 Mar 2014 23:02:54 -0500
From: dranikist@gmail.com (R Manard)
To: ------------------- at gmail.com

To the best of my knowledge
"

Really kid? That’s how you respond to technical criticism? By invading other’s privacy and sending them dick-jokes?
Christ. Somebody kick this loser.

Let’s keep it professional. You’re breaking forum rules at the moment.
Please read them and stop sending me weird spam to harass me an I’ll stop
responding. In fact send me another couple and I’ll fail to respond to show
my better nature.

Anyway. SOME INTEL MOTHERBOARD CD’S OF OLD HAD COOL STUFF ON THEM
Over the years Intel has made many versions of helper code they sent with
their mother boards on a cd and available at their website. They said they
were going to show superior value by offering helper stuff that would work
on the bios and intel cpu combo with windows. They spent heaps of cash and
got pretty far but in the end they fail to produce a revenue stream to
support their plans.
The decided to focus instead on the other end of it all and make their own
compiler and helper suite that does most of the stuff their old stuff did
and new stuff that helps developers make better code designed for their cpu
and motherboards with windows.
I wish they would have succeeded. I’d buy a motherboard and cpu that could
drastically reduce the run time size of my games and their resources. I’d
pay extra for the ability of my gear to watch my games run and rearrange
the actual program as it runs. Making new threads and special functions out
of parts of the games functions. Even just in the interest of computer
science I like the idea of putting the innovation pressure more on the
makers of the computers and not on the game makers.
I looked for a few minuets but I could not find any old documentation about
the inner workings of stuff long gone. I think some of it was closely
guarded.
If no one believes it existed that’s ok. You can even mail me in private
saying I’m wrong. Just please don’t call me names because that’s not cool.On Thu, Mar 27, 2014 at 2:28 AM, mattbentley wrote:

Shortly after I posted my message above I received a message from R
Manard with the following:
"
-------- Original Message --------
Subject: Latrice has a small penis
Date: Wed, 26 Mar 2014 23:02:54 -0500
From: R Manard <>
To:

To the best of my knowledge
"

Really kid? That’s how you respond to technical criticism? By invading
other’s privacy and sending them dick-jokes?
Christ. Somebody kick this loser.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Message-ID:
<CAKCUQMbM=QHQ0xAsbQbnOVeUhbvijYyrKGuEovzmLtfDGS1QhQ at mail.gmail.com>
Content-Type: text/plain; charset=“iso-8859-1”

Let’s keep it professional. You’re breaking forum rules at the moment.
Please read them and stop sending me weird spam to harass me an I’ll stop
responding. In fact send me another couple and I’ll fail to respond to show
my better nature.

You do realize that he was accusing YOU of being unprofessional,
right? Also, what “forum” rules are you refering to?

Anyway. SOME INTEL MOTHERBOARD CD’S OF OLD HAD COOL STUFF ON THEM
Over the years Intel has made many versions of helper code they sent with
their mother boards on a cd and available at their website. They said they
were going to show superior value by offering helper stuff that would work
on the bios and intel cpu combo with windows. They spent heaps of cash and
got pretty far but in the end they fail to produce a revenue stream to
support their plans.

Unless you can point to something specific, I think that all of us are
going to have to assume that you’re misremembering some sort of
developer’s kit (e.g. compilers + code samples) that was only notable
for the fact that it had been included at all.

Is it theoretically possible to create a tool that will look at byte
code & transform it into a faster version? Yes, but the resulting code
will be very processor-optimized (meaning that it won’t run as well…
or possibly at all, on another processor), and probably won’t be much
faster. A TCC (which does almost no optimizations) vs MSVC test for
producing Fibonacci numbers resulted in the MSVC-compiled program only
winning by 15%. The compile-gcc-then-have-it-compile-itself test was
much more impressive, but TCC does almost no optimizations, which
makes it easy game. Most programs are not likely to be compiled on
something like TCC, there are limits on the optimizations you can do,
and doing optimizations without access to the original source code has
the tendency of producing bugs.

End conclusion? You’re probably misremembering exactly what it was,
and even if you aren’t the improvements would most likely have been
minor at best, and detrimental on every other processor.

The decided to focus instead on the other end of it all and make their own
compiler and helper suite that does most of the stuff their old stuff did
and new stuff that helps developers make better code designed for their cpu
and motherboards with windows.

In other words, it was code optimizations. Why did they REALLY do
this? Because it’s massively easier to do this in the compiler than
outside of it: and massively less bug-prone as well. Could you do this
in a processor? Sure, but the chip would be huge, and cost more than
the benefit that it provided: in fact, reinterpreting the byte code on
the fly could very well be slower. You could claim that all modern
micro-code processors do this, but that’s a gross distortion of what
microcode is.

I wish they would have succeeded.

They did. It’s called ICC. It’s a compiler, and I’m pretty certain at
least used to include some optimized libraries. I half-recall some
blather from Intel about how it produced optimal code for their
processors, I think I even downloaded it. But normal people don’t want
to optimize for a single processor within a line of processors unless
they’re doing embedded work, because it’s a waste of time.

I’d buy a motherboard and cpu that could
drastically reduce the run time size of my games and their resources.

They likely meant 1-3 percent, not 50%.

I’d
pay extra for the ability of my gear to watch my games run and rearrange
the actual program as it runs. Making new threads and special functions out
of parts of the games functions.

That’s the job of a compiler, and before that of the programmer. To
paraphrase Duff: “With enough effort, anything can be made to run
slowly”.

Even just in the interest of computer
science I like the idea of putting the innovation pressure more on the
makers of the computers and not on the game makers.

If you actually claim to be a programmer, then you should feel ashamed
of typing that. It’s tantamount to saying that you want other people
to work hard so that you can relax.> Date: Thu, 27 Mar 2014 03:42:27 -0500

From: R Manard
To: SDL Development List
Subject: Re: [SDL] Question about SDL2 memory management

mattbentley wrote:

R Manard wrote:

Windows together with an Intel chip could stop memory behavior that is redundant and useless after it executes for a while .

This is, to the best of my knowledge, complete rubbish.

Correct.

R Manard wrote:

Anyway. SOME INTEL MOTHERBOARD CD’S OF OLD HAD COOL STUFF ON THEM
Over the years Intel has made many versions of helper code they sent with their mother boards on a cd and available at their website. They said they were going to show superior value by offering helper stuff that would work on the bios and intel cpu combo with windows. They spent heaps of cash and got pretty far but in the end they fail to produce a revenue stream to support their plans.

You clearly don’t know what you are talking about.
“Helper stuff” that would work at the BIOS level? Not only is that pretty much impossible, that is also laughable.
You obviously have no clue what the BIOS actually does.

The decided to focus instead on the other end of it all and make their own compiler and helper suite that does most of the stuff their old stuff did and new stuff that helps developers make better code designed for their cpu and motherboards with windows.

You got this sorta right. They don’t call it “helper suite”. They have debugging tools available, but NOTHING works at the motherboard level.

I wish they would have succeeded. I’d buy a motherboard and cpu that could drastically reduce the run time size of my games and their resources. I’d pay extra for the ability of my gear to watch my games run and rearrange the actual program as it runs. Making new threads and special functions out of parts of the games functions.

Again, you have no idea what you are talking about. How in the world could a motherboard reduce the size of a game’s size ? You are back in lala land.

Even just in the interest of computer science I like the idea of putting the innovation pressure more on the makers of the computers and not on the game makers.
I looked for a few minuets but I could not find any old documentation about the inner workings of stuff long gone. I think some of it was closely guarded.

That is just it, this is science, this isn’t black magic. What you described is, and always will be impossible. You can’t find any old documentation since none ever existed.

If no one believes it existed that’s ok. You can even mail me in private saying I’m wrong. Just please don’t call me names because that’s not cool.

So, you think it is OK to spout this nonsense on a open mailing list, but, you don’t want corrections to your nonsense shown in the same list.
Sorry, but, when people flat out state nonsensical things, then, they should be called on it.

The only way to debug memory issues is with either something like valgrind, electric fence, or another library that keeps track of all memory allocations.
MS has this ability that can be turned on with a few function calls as well.
There is no magic wand that can be waived over the BIOS and motherboard to magically “fix” allocation problems.

This guy must be a troll.
[Rolling Eyes]

Message-ID: <1395976175.m2f.42915 at forums.libsdl.org>
Content-Type: text/plain; charset=“iso-8859-1”

Even just in the interest of computer science I like the idea of putting the innovation pressure more on the makers of the computers and
not on the game makers. I looked for a few minuets but I could not find any old documentation about the inner workings of stuff long
gone. I think some of it was closely guarded.

That is just it, this is science, this isn’t black magic. What you described is, and always will be impossible. You can’t find any old
documentation since none ever existed.

Technically, embedded stuff like a BIOS can actually be pretty hairy
(apparently it’s gotten better, since recent chips reliably have some
cache that you can use before you turn on the RAM), but certainly I
think that Manard’s firing blind here, especially since the BIOS is
not exactly a common development target for modern programmers…

There is no magic wand that can be waived over the BIOS and motherboard to magically “fix” allocation problems.

Wait, you put double quotes around fix, I think that means breaking
the motherboard with a sledge hammer qualifies…

This guy must be a troll.
[Rolling Eyes]

I’d say no, but I don’t think that you can take what he says at face
value either. I remember there being a language barrier, he’s always
seemed more enthusiastic than experienced, and sometimes he makes what
seem like really spotty suggestions. I think I might have even gotten
into a shouting match with him once or twice (admittedly, I’ve also
done that with Mason Wheeler, and I actually have a decent amount of
faith in Mason… just not on THOSE subjects).> Date: Fri, 28 Mar 2014 03:09:35 +0000

From: “oldfella”
To: sdl at lists.libsdl.org
Subject: Re: [SDL] Question about SDL2 memory management

---- oldfella wrote:=============

mattbentley wrote:

R Manard wrote:

Windows together with an Intel chip could stop memory behavior that is redundant and useless after it executes for a while .

This is, to the best of my knowledge, complete rubbish.

Correct.

“in my opinion” NOT CORRECT. PLUS I WOULD LIKE TO HAVE YOUR “RUBBISH”

R Manard wrote:

Anyway. SOME INTEL MOTHERBOARD CD’S OF OLD HAD COOL STUFF ON THEM
Over the years Intel has made many versions of helper code they sent with their mother boards on a cd and available at their website. They said they were going to show superior value by offering helper stuff that would work on the bios and intel cpu combo with windows. They spent heaps of cash and got pretty far but in the end they fail to produce a revenue stream to support their plans.

You clearly don’t know what you are talking about.
“Helper stuff” that would work at the BIOS level? Not only is that pretty much impossible, that is also laughable.
You obviously have no clue what the BIOS actually does.

you clearly don’t know what you are talking about. Your rebuttal is that it’s pretty much impossible. By your own admission it’s possible. Then you go on to say even though I have stated something you believe is possible the fact that I have said this possible thing proves to you that I don’t understand the subject at all. That’s laughable .

The decided to focus instead on the other end of it all and make their own compiler and helper suite that does most of the stuff their old stuff did and new stuff that helps developers make better code designed for their cpu and motherboards with windows.

You got this sorta right. They don’t call it “helper suite”. They have debugging tools available, but NOTHING works at the motherboard level.

I never said they call it that. Did you think I was claiming also that the made a product called “old stuff”? I never said it works on the motherboard level. But does it? It may depend on how you define it. I was just saying they work as a team.



Maybe it did “work on the motherboard level”.

I wish they would have succeeded. I’d buy a motherboard and cpu that could drastically reduce the run time size of my games and their resources. I’d pay extra for the ability of my gear to watch my games run and rearrange the actual program as it runs. Making new threads and special functions out of parts of the games functions.

Again, you have no idea what you are talking about. How in the world could a motherboard reduce the size of a game’s size ? You are back in lala land.

Again, still, you talk with very little comprehension of the words used. I was talking about the teamwork here. “The motherboard that is so awesome that it supports the chip that has input and output that allows such a thing”, is a more expressive way of saying it that you may be able to grasp. If you still can’t understand the words I’m using or the ideas, I’d be glad to tutor you in private. I have explained these things in terms that helped a clinically retarded person so I am pretty sure I can help.

Even just in the interest of computer science I like the idea of putting the innovation pressure more on the makers of the computers and not on the game makers.
I looked for a few minuets but I could not find any old documentation about the inner workings of stuff long gone. I think some of it was closely guarded.

That is just it, this is science, this isn’t black magic. What you described is, and always will be impossible. You can’t find any old documentation since none ever existed.

Your rudeness aside, you can’t find anything to disprove me because I am probably right. I am not perfect. I could always be wrong. But I have not been convinced by your argument.

If no one believes it existed that’s ok. You can even mail me in private saying I’m wrong. Just please don’t call me names because that’s not cool.

So, you think it is OK to spout this nonsense on a open mailing list, but, you don’t want corrections to your nonsense shown in the same list.
Sorry, but, when people flat out state nonsensical things, then, they should be called on it.

The only way to debug memory issues is with either something like valgrind, electric fence, or another library that keeps track of all memory allocations.
MS has this ability that can be turned on with a few function calls as well.
There is no magic wand that can be waived over the BIOS and motherboard to magically “fix” allocation problems.

This guy must be a troll.
[Rolling Eyes]

It’s ok that you think you have a good handle on what intel can make their motherboards, code, and chips do in tandem, with, machine code as it executes in memory. Calling me a troll is not cool. Let us reason together, not throw feces. I’m done with this subject in the mailing list unless it somehow relates to sdl2 or something else that belongs in this email list. I think that would be spam, beating that dead horse.
In private however I’d be glad to continue for as long as anyone wants. That’s not to say anyone’s opinion is lesser than mine or that anyone needs to accept my opinion. I just want to stop, what has come to be, in my opinion, spam. I have a forum that you could take it to as well.

R A Manard whisper8.com dranikist at gmail dot com

Tomeamis wrote:

Nathaniel J Fries wrote:

“I overloaded new and delete to output allocation info”

SDL does not use the new and delete operators, it uses SDL_malloc and SDL_free. By default, these map to the C library’s malloc() and free() functions.

Yes, that’s precisely why I’m worried that the memory increase is courtesy of SDL. My app uses new and delete so all heap allocations by my app should be logged by the overloaded operators.

Also, I have finally managed linux so I’m going to post valgrind results in the evening. WinDBG apparently needs a PDB file which is not produced by GCC (my compiler of choice) and VC++ doesn’t support all the C++11 features I need so WinDBG is out. Although the heap reports I’ve gathered with just system library symbols from Microsoft’s servers, the heaps are stable. The numbers were far too low though (half a kilobyte), so I wrote them off as more or less bogus.

Visual C and mingw both use a simple wrapper around Win32’s HeapAlloc/HeapFree API for malloc and free. It’s possible to replace it with a custom allocator, but you have to do different things between visual C and mingw. Instead, you might try the HeapWalk API: http://msdn.microsoft.com/en-us/library/windows/desktop/aa366710(v=vs.85).aspx

basically, just store a list of what was allocated prior to SDL_init (the CRT is going to allocate stuff itself), and compare that list to what’s on the heap after SDL_Quit returns.

however, this behavior doesn’t sound consistent with a memory leak, because it stops. Other explanations might be: lazy initialization, heap fragmentation, or too many small allocations.------------------------
Nate Fries

Sorry for the late reply. Ubuntu, apparently, doesn’t like my laptop very much.

Anyways, I debugged my code using Valgrind so that there were no leaks or errors reported, then compiled it for Windows again and the memory keeps increasing. So I’d say it means that ther is either something weird going on between my app and Windows memory manager, or there is some kind of problem with the D3D implementation of SDL_renderer. I’ll try to forcce SDL to use OpenGL on Windows too so I can compare.

Nathaniel J Fries wrote:>

Tomeamis wrote:

Nathaniel J Fries wrote:

“I overloaded new and delete to output allocation info”

SDL does not use the new and delete operators, it uses SDL_malloc and SDL_free. By default, these map to the C library’s malloc() and free() functions.

Yes, that’s precisely why I’m worried that the memory increase is courtesy of SDL. My app uses new and delete so all heap allocations by my app should be logged by the overloaded operators.

Also, I have finally managed linux so I’m going to post valgrind results in the evening. WinDBG apparently needs a PDB file which is not produced by GCC (my compiler of choice) and VC++ doesn’t support all the C++11 features I need so WinDBG is out. Although the heap reports I’ve gathered with just system library symbols from Microsoft’s servers, the heaps are stable. The numbers were far too low though (half a kilobyte), so I wrote them off as more or less bogus.

Visual C and mingw both use a simple wrapper around Win32’s HeapAlloc/HeapFree API for malloc and free. It’s possible to replace it with a custom allocator, but you have to do different things between visual C and mingw. Instead, you might try the HeapWalk API: http://msdn.microsoft.com/en-us/library/windows/desktop/aa366710(v=vs.85).aspx

basically, just store a list of what was allocated prior to SDL_init (the CRT is going to allocate stuff itself), and compare that list to what’s on the heap after SDL_Quit returns.

however, this behavior doesn’t sound consistent with a memory leak, because it stops. Other explanations might be: lazy initialization, heap fragmentation, or too many small allocations.