To expand on Bert's response, I see two directions for this to go: either OP is 
unaware of some R object references that are in fact still being referenced 
somewhere, or the specialized contributed packages being used have memory leaks 
(not unheard of... C can require considerable effort to avoid failing to 
release resources). (It is also possible but maybe not likely that in the right 
forum there will be someone who immediately recognizes this issue... but 
probably not what you should be betting on.)

Both of these possibilities will likely require detailed knowledge (likely 
maintainer-level, or at least someone with experience debugging memory leaks) 
of the specific packages involved. In order for such a person to dig into this 
they will need a reproducible (hopefully short and with small data file 
requirements) example that they can run over and over as they troubleshoot. 

I recommend that you try to start building this example sooner rather than 
later ... maybe include a link to it or paste it into your next request (email 
to maintainer? a last gasp post here?) to give whoever has that very narrow set 
of abilities an incentive to look at it. Not having such an example can make it 
easier to just skip your request as being too vague and time-consuming to 
investigate.

Note that sending your email in plain text (a setting in your email software) 
rather than the HTML that this was sent in will help avoid us receiving 
frustrating glitches in your sample code.

Google "cran reprex" and read the vignette for further help on making an 
example.

On September 4, 2025 3:01:08 PM PDT, Bert Gunter <bgunter.4...@gmail.com> wrote:
>As I understand it and you, this kind of specialized technical question is
>usually not a good fit to this list about general issues in R programming,
>though someone may respond here of course. Alternatively, you may find it
>useful to post on one (or some?) of the R SIGS (Special Interest Groups)
>listed at https://www.r-project.org/mail.html  to see if one of them might
>be a better fit. (Though some listed there may be inactive). Note also that
>some R packages dealing with image processing have their own dedicated
>lists.
>
>Happy hunting.
>
>Cheers,
>Bert
>
>On Thu, Sep 4, 2025 at 2:17 PM Steve Rowley via R-help <r-help@r-project.org>
>wrote:
>
>> I have a question about repeated image processing and recovering memory via
>> garbage collection.
>>
>> A couple images are displayed simultaneously for analysis, using
>> split.screen().  I'm looping over a large collection of images, using
>> jpeg/readJPEG(), png/readPNG(), and caTools/read.gif() to load an image
>> into memory from a file.  Then I use erase.screen() to erase the previous
>> image, use plot() to set up a plotting area, and display the image with
>> rasterImage().  Then the user elects some processing, and we move on to the
>> next image(s).
>>
>> I'm very carefully not holding references to any of the previous images.
>> GC is indeed happening, but memory quickly fills up.  It certainly *looks*
>> as though the image memory is not being released: printing out trace info
>> using mem_used()[[1]] says memory use increases with each image, by about
>> the image size.  Forcing periodic GC's, measuring memory used before and
>> after, shows that no memory is recovered.
>>
>> Some questions:
>>
>> (1) Is it known that processing images in this way will lead to allocating
>> memory that is not recovered by GC?
>>
>> (2) Are there any tools you'd recommend to see exactly *what* is filling up
>> memory, just in case it's not previous images, but some other problem?
>>
>> This is R 4.4.2 (for now).  Running MacOS on an ARM processor.
>> ___________
>> Steve Rowley <s...@alum.mit.edu> Zoom: 839 529 4589
>> <https://us04web.zoom.us/j/8395294589?pwd=dlQ4MUFHK1NFOCtoZFpUNFRtZ2lSQT09
>> >
>> It is very dark & after 2000.  If you continue, you are likely to be eaten
>> by a bleen.
>>
>>         [[alternative HTML version deleted]]
>>
>> ______________________________________________
>> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
>> https://stat.ethz.ch/mailman/listinfo/r-help
>> PLEASE do read the posting guide
>> https://www.R-project.org/posting-guide.html
>> and provide commented, minimal, self-contained, reproducible code.
>>
>
>       [[alternative HTML version deleted]]
>
>______________________________________________
>R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
>https://stat.ethz.ch/mailman/listinfo/r-help
>PLEASE do read the posting guide https://www.R-project.org/posting-guide.html
>and provide commented, minimal, self-contained, reproducible code.

-- 
Sent from my phone. Please excuse my brevity.

______________________________________________
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide https://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Reply via email to