[Skim-app-users] Memory leak?

[Jan David Hauck]

I have to come back again to the thread from earlier this year about the
likely El Capitan PDFKit Memory leak.

It seems that something has changed from the previously reported behavior,
it now seems that some memory is given back to the system, but still not
all.

I had 30 pdfs open and it said it was using 23 GB of RAM (total memory).
Upon closing 8 of them it went down to 20 GB.
After closing Skim and restoring the session these 22 now newly opened pdfs
only needed about 2 GB.
But after keeping Skim open for a while, reading through pdfs, annotating
etc. it slowly kept growing again, now it's back to 7 GB, roughly 24 hours
later.
Shouldn't it give back memory automatically even when not closing pdfs?

I'm afraid, I now far too little about how this works or should work, so
maybe it's just that I open too many pdfs or that my pdfs are too big. But
I'm wondering if others can also still report odd behavior, and if there
might still be something wrong with PDFKit?
Did Apple ever respond to any of the bug reports?



PS: Same behavior in Preview.

On Dec 20, 2015, at 23:18, José Miguel Figueroa-O'Farrill <
Hi,
I’m running Skim Version 1.4.16 (90) on Mac OS X Version 10.11.2 (15C50).
I wonder whether anyone else has seen this behaviour: Skim is using a huge
amount of RAM. According to Activity Monitor, Skim is using
Skim | 13.42 GB | 7.49 GB | 11 | 283
in the notation
App | Memory | Compressed Memory | Threads | Ports
In fact, the system ran out of application memory yesterday and I think it
was due to Skim. (It was one of two apps which were not responding.)
I’ve gone back to 1.4.15 (89) for now.
Cheers,
José
BTW, it does seem like more people are seeing this. Moreover, it is also
seen in Preview. That means, as I would expect if it’s really there, that
it’s a bug in PDFKit in ElCap (one of many serious bugs, unfortunately).
I’ve reported this to Apple, but given how (non) responsive they are on the
even more obvious and visible (and simpler to fix!) bugs, I don’t expect
them to fix this before 10.12.
Christiaan

[José Miguel Figueroa-O'Farrill]

I still experience the same problem. Long gone are the days where I could just keep Skim running for days on end. I now have gotten used to having to quit it periodically to get the memory back. So my guess is that Apple has not addressed the problem.

José

I have to come back again to the thread from earlier this year about the likely El Capitan PDFKit Memory leak.
It seems that something has changed from the previously reported behavior, it now seems that some memory is given back to the system, but still not all.
I had 30 pdfs open and it said it was using 23 GB of RAM (total memory).
Upon closing 8 of them it went down to 20 GB.
After closing Skim and restoring the session these 22 now newly opened pdfs only needed about 2 GB.
But after keeping Skim open for a while, reading through pdfs, annotating etc. it slowly kept growing again, now it's back to 7 GB, roughly 24 hours later.
Shouldn't it give back memory automatically even when not closing pdfs?
I'm afraid, I now far too little about how this works or should work, so maybe it's just that I open too many pdfs or that my pdfs are too big. But I'm wondering if others can also still report odd behavior, and if there might still be something wrong with PDFKit?
Did Apple ever respond to any of the bug reports?
PS: Same behavior in Preview.

Hi,
I’m running Skim Version 1.4.16 (90) on Mac OS X Version 10.11.2 (15C50).
I wonder whether anyone else has seen this behaviour: Skim is using a huge amount of RAM. According to Activity Monitor, Skim is using
Skim | 13.42 GB | 7.49 GB | 11 | 283
in the notation
App | Memory | Compressed Memory | Threads | Ports
In fact, the system ran out of application memory yesterday and I think it was due to Skim. (It was one of two apps which were not responding.)
I’ve gone back to 1.4.15 (89) for now.
Cheers,
José

BTW, it does seem like more people are seeing this. Moreover, it is also seen in Preview. That means, as I would expect if it’s really there, that it’s a bug in PDFKit in ElCap (one of many serious bugs, unfortunately). I’ve reported this to Apple, but given how (non) responsive they are on the even more obvious and visible (and simpler to fix!) bugs, I don’t expect them to fix this before 10.12.
Christiaan
------------------------------------------------------------------------------
_______________________________________________
Skim-app-users mailing list
https://lists.sourceforge.net/lists/listinfo/skim-app-users

Prof José Figueroa-O'Farrill
School of Mathematics
University of Edinburgh
PGP Key: 0x6A6BD529 (MIT PGP Key Server)

The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

[Christiaan Hofman]

Normally memory should be given back. Some memory may hang on for caching purposes, to make things run more smoothly, but that ideally should only be limited.

We did fix some memory leaks in the previous release, so you should see some improvement. Though that probably should be modest, they weren’t really big ones. Currently, I cannot see any memory leaks in the analyzing tools. (Though that does not catch all memory leaks, though it should catch memory leaks from Cocoa programming). Though I do get the impression that PDFKit in 10.11 does run up memory a lot. I don’t know if that is a leak or excessive caching. I can’t find where it is, and if it is in PDFKit it certainly is nothing we can do about. And seeing it in Preview also points to problems in PDFKit.

Christiaan

Post by José Miguel Figueroa-O'Farrill
I still experience the same problem. Long gone are the days where I could just keep Skim running for days on end. I now have gotten used to having to quit it periodically to get the memory back. So my guess is that Apple has not addressed the problem.
José

I have to come back again to the thread from earlier this year about the likely El Capitan PDFKit Memory leak.
It seems that something has changed from the previously reported behavior, it now seems that some memory is given back to the system, but still not all.
I had 30 pdfs open and it said it was using 23 GB of RAM (total memory).
Upon closing 8 of them it went down to 20 GB.
After closing Skim and restoring the session these 22 now newly opened pdfs only needed about 2 GB.
But after keeping Skim open for a while, reading through pdfs, annotating etc. it slowly kept growing again, now it's back to 7 GB, roughly 24 hours later.
Shouldn't it give back memory automatically even when not closing pdfs?
I'm afraid, I now far too little about how this works or should work, so maybe it's just that I open too many pdfs or that my pdfs are too big. But I'm wondering if others can also still report odd behavior, and if there might still be something wrong with PDFKit?
Did Apple ever respond to any of the bug reports?
PS: Same behavior in Preview.

Hi,
I’m running Skim Version 1.4.16 (90) on Mac OS X Version 10.11.2 (15C50).
I wonder whether anyone else has seen this behaviour: Skim is using a huge amount of RAM. According to Activity Monitor, Skim is using
Skim | 13.42 GB | 7.49 GB | 11 | 283
in the notation
App | Memory | Compressed Memory | Threads | Ports
In fact, the system ran out of application memory yesterday and I think it was due to Skim. (It was one of two apps which were not responding.)
I’ve gone back to 1.4.15 (89) for now.
Cheers,
José

BTW, it does seem like more people are seeing this. Moreover, it is also seen in Preview. That means, as I would expect if it’s really there, that it’s a bug in PDFKit in ElCap (one of many serious bugs, unfortunately). I’ve reported this to Apple, but given how (non) responsive they are on the even more obvious and visible (and simpler to fix!) bugs, I don’t expect them to fix this before 10.12.
Christiaan

------------------------------------------------------------------------------

[Jan David Hauck]

What had surprised me was that closing PDFs did make a difference
immediately
(at least as far as Activity monitor displays correct values), so it looked
like something had changed, but still not enough.
I haven't thoroughly tested it with Preview, since I don't use it very
often and usually don't have many pdfs open for a longer time, but Preview
also always goes up to 3 to 4 GB even with only one or two PDFs open, so it
looks very much like the same problem.

Is anyone already running the OS 10.12 beta and could report whether there
are any sign of improvements/changes in PDFKit?

(Or at least some sign of hope that Apple will do an overhaul of PDFKit,
since memory doesn't seem to be the only problem, for example, ignoring
ligatures in some fonts, or screwing up the encoding of some PDFs when they
are changed and saved.)

Post by Christiaan Hofman
Normally memory should be given back. Some memory may hang on for caching
purposes, to make things run more smoothly, but that ideally should only be
limited.
We did fix some memory leaks in the previous release, so you should see
some improvement. Though that probably should be modest, they weren’t
really big ones. Currently, I cannot see any memory leaks in the analyzing
tools. (Though that does not catch all memory leaks, though it should catch
memory leaks from Cocoa programming). Though I do get the impression that
PDFKit in 10.11 does run up memory a lot. I don’t know if that is a leak or
excessive caching. I can’t find where it is, and if it is in PDFKit it
certainly is nothing we can do about. And seeing it in Preview also points
to problems in PDFKit.
Christiaan

On Sep 1, 2016, at 14:30, José Miguel Figueroa-O'Farrill <
I still experience the same problem. Long gone are the days where I

could just keep Skim running for days on end. I now have gotten used to
having to quit it periodically to get the memory back. So my guess is that
Apple has not addressed the problem.

José

Post by Jan David Hauck
I have to come back again to the thread from earlier this year about

the likely El Capitan PDFKit Memory leak.

Post by Jan David Hauck
It seems that something has changed from the previously reported

behavior, it now seems that some memory is given back to the system, but
still not all.

Post by Jan David Hauck
I had 30 pdfs open and it said it was using 23 GB of RAM (total memory).
Upon closing 8 of them it went down to 20 GB.
After closing Skim and restoring the session these 22 now newly opened

pdfs only needed about 2 GB.

Post by Jan David Hauck
But after keeping Skim open for a while, reading through pdfs,

annotating etc. it slowly kept growing again, now it's back to 7 GB,
roughly 24 hours later.

Post by Jan David Hauck
Shouldn't it give back memory automatically even when not closing pdfs?
I'm afraid, I now far too little about how this works or should work,

so maybe it's just that I open too many pdfs or that my pdfs are too big.
But I'm wondering if others can also still report odd behavior, and if
there might still be something wrong with PDFKit?

Post by Jan David Hauck
Did Apple ever respond to any of the bug reports?
PS: Same behavior in Preview.

On Dec 20, 2015, at 23:18, José Miguel Figueroa-O'Farrill <
Hi,
I’m running Skim Version 1.4.16 (90) on Mac OS X Version 10.11.2

(15C50).

Post by Jan David Hauck

I wonder whether anyone else has seen this behaviour: Skim is using a

huge amount of RAM. According to Activity Monitor, Skim is using

Post by Jan David Hauck

Skim | 13.42 GB | 7.49 GB | 11 | 283
in the notation
App | Memory | Compressed Memory | Threads | Ports
In fact, the system ran out of application memory yesterday and I

think it was due to Skim. (It was one of two apps which were not
responding.)

Post by Jan David Hauck

I’ve gone back to 1.4.15 (89) for now.
Cheers,
José

BTW, it does seem like more people are seeing this. Moreover, it is

also seen in Preview. That means, as I would expect if it’s really there,
that it’s a bug in PDFKit in ElCap (one of many serious bugs,
unfortunately). I’ve reported this to Apple, but given how (non) responsive
they are on the even more obvious and visible (and simpler to fix!) bugs, I
don’t expect them to fix this before 10.12.

Post by Jan David Hauck
Christiaan

------------------------------------------------------------
------------------
_______________________________________________
Skim-app-users mailing list
https://lists.sourceforge.net/lists/listinfo/skim-app-users