On Monday, 20 January 2020 at 22:16:55 UTC+5:30, ga...@u.washington.edu wrote:
> On Monday, January 20, 2020 at 3:19:09 AM UTC-8, Themos Tsikas wrote:
> > On Tuesday, 14 January 2020 23:08:19 UTC, ga...@u.washington.edu wrote:
> > > Even considering that, though, I don't see how this program has two
> > > leaked allocations, and both on line 12.
>
> > This is a side-effect of the -C=undefined option. More runtime
> > data structures are created and maintained to keep track of undefined
> > variables and there's an extra leak associated with them.
> > Without that option we only see one leak at that line number.
> And the additional data structure is the same size!
>
> Reminds me of some years ago, working with a company on some
> big complicated system, and kept having it run out of memory,
> so I complained that it had a memory leak. After lots of
> testing, they claimed that it didn't.
>
> In the end, it turned out that the system was multithreaded with
> three threads: input thread, processing thread, and output thread.
>
> The processing thread would generate some data structure in memory
> and pass it to the output thread, which would then write results
> out and free the data structure.
>
> There was, however, no system to make sure that one thread didn't
> get way ahead and fill up memory with results.
>
> As the output was large (ASCII text file), I piped the output
> through gzip. That, in turn, slowed down the output thread, but
> not the processing thread, until it filled up memory with results.
>
> (32 bit days, so 3GB limit. The actual output was much less.)