Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #47879 > unrolled thread

Debugging memory leaks

Back to article view | Back to comp.lang.python

Contents

  Debugging memory leaks writeson <doug.farrell@gmail.com> - 2013-06-12 18:24 -0700
    Re: Debugging memory leaks dieter <dieter@handshake.de> - 2013-06-13 08:29 +0200
      Re: Debugging memory leaks Giorgos Tzampanakis <giorgos.tzampanakis@gmail.com> - 2013-06-13 20:15 +0000
        Re: Debugging memory leaks Steve Simmons <square.steve@gmail.com> - 2013-06-13 22:45 +0100
        Re: Debugging memory leaks Chris Angelico <rosuav@gmail.com> - 2013-06-14 08:36 +1000
        Re: Debugging memory leaks Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-14 02:40 +0000
          Re: Debugging memory leaks Chris Angelico <rosuav@gmail.com> - 2013-06-14 19:30 +1000
          Re: Debugging memory leaks Giorgos Tzampanakis <giorgos.tzampanakis@gmail.com> - 2013-06-14 22:57 +0000
            Re: Debugging memory leaks Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-15 01:39 +0000
          Re: Debugging memory leaks dieter <dieter@handshake.de> - 2013-06-15 08:52 +0200
          Re: Debugging memory leaks Chris Angelico <rosuav@gmail.com> - 2013-06-15 17:21 +1000
          Re: Debugging memory leaks dieter <dieter@handshake.de> - 2013-06-16 08:18 +0200
        Re: Debugging memory leaks rusi <rustompmody@gmail.com> - 2013-06-14 06:53 -0700
          Re: Debugging memory leaks Chris Angelico <rosuav@gmail.com> - 2013-06-15 10:11 +1000
          Re: Debugging memory leaks Ben Finney <ben+python@benfinney.id.au> - 2013-06-15 10:16 +1000
            Re: Debugging memory leaks rusi <rustompmody@gmail.com> - 2013-06-14 20:16 -0700
              Re: Debugging memory leaks Ben Finney <ben+python@benfinney.id.au> - 2013-06-15 21:23 +1000
                Re: Debugging memory leaks rusi <rustompmody@gmail.com> - 2013-06-15 04:35 -0700
                  Re: Debugging memory leaks Chris Angelico <rosuav@gmail.com> - 2013-06-15 21:54 +1000
    Re: Debugging memory leaks writeson <doug.farrell@gmail.com> - 2013-06-13 11:07 -0700
      Re: Debugging memory leaks Dave Angel <davea@davea.name> - 2013-06-13 14:44 -0400
    Re: Debugging memory leaks rusi <rustompmody@gmail.com> - 2013-06-14 05:36 -0700
    Re: Debugging memory leaks "Frank Millman" <frank@chagford.com> - 2013-06-21 08:50 +0200

Page 1 of 2  [1] 2  Next page →

#47879 — Debugging memory leaks

Hi all,

I've written a program using Twisted that uses SqlAlchemy to access a database using threads.deferToThread(...) and SqlAlchemy's scoped_session(...). This program runs for a long time, but leaks memory slowly to the point of needing to be restarted. I don't know that the SqlAlchemy/threads thing is the problem, but thought I'd make you aware of it.

Anyway, my real question is how to go about debugging memory leak problems in Python, particularly for a long running server process written with Twisted. I'm not sure how to use heapy or guppy, and objgraph doesn't tell me enough to locate the problem. If anyone as any suggestions or pointers it would be very much appreciated!

Thanks in advance,
Doug

[toc] | [next] | [standalone]

#47906

writeson <doug.farrell@gmail.com> writes:

> ...
> Anyway, my real question is how to go about debugging memory leak problems in Python, particularly for a long running server process written with Twisted. I'm not sure how to use heapy or guppy, and objgraph doesn't tell me enough to locate the problem.

Analysing memory leaks is really difficult: huge amounts of data
is involved and usually, it is almost impossible to determine which
of the mentioned objects are leaked and which are rightfully in use.
In addition, long running Python processes usually have degrading
memory use - due to memory fragmentation. There is nothing you
can do against this.

Therefore: if the leak seems to be small, it may be much more
advicable to restart your process periodically (during times
where a restart does not hurt much) rather than try to find
(and fix) the leaks. Only when the leak is large enough that
it would force you to too frequent restarts, a deeper
analysis may be advicable (large leaks are easier to locate as well).


I have analysed memory leaks several times for Zope applications.

Zope helped me much by its "Top Refcount" functionality.
This uses the fact that a class/type instance (in many cases)
holds a reference to the corresponding class/type instance
(it seems not to work for all elementary types).
Thus looking at the refcount of the class/type gives you
an indication how many instances of this class/type are around.
Zope presents this information sorted by number.
Then you send requests against Zope and reexamine the information:
You get something like:

 Class                  June 13, 2013 8:18 am 	June 13, 2013 8:18 am 	Delta
...ApplicationManager 	15                      22                      +7
...DebugManager 	9                       12                      +3 

In the case above, my requests have created 7 additional
"ApplicationManager" and 3 additional "DebugManager" instances.

If Zope objects for which this functionality works leak,
then this is a powerful tool to detect those object classes.

You could implement something similar for your server.


As mentioned, the approach does not work for (many; all?) elementary
Python types. Thus, if the leak involves only those instances, it
cannot be detected this way.

Memory leaks are often introduced by C extensions - and do not
involve Python objects (but leak C level memory). Those, too,
cannot be analysed by Python level approaches.

[toc] | [prev] | [next] | [standalone]

#48017

On 2013-06-13, dieter wrote:

>> ...  Anyway, my real question is how to go about debugging memory leak
>> problems in Python, particularly for a long running server process
>> written with Twisted. I'm not sure how to use heapy or guppy, and
>> objgraph doesn't tell me enough to locate the problem.
>
> Analysing memory leaks is really difficult: huge amounts of data is
> involved and usually, it is almost impossible to determine which of the
> mentioned objects are leaked and which are rightfully in use.  In
> addition, long running Python processes usually have degrading memory
> use - due to memory fragmentation. There is nothing you can do against
> this.
>
> Therefore: if the leak seems to be small, it may be much more advicable
> to restart your process periodically (during times where a restart does
> not hurt much) rather than try to find (and fix) the leaks. Only when
> the leak is large enough that it would force you to too frequent
> restarts, a deeper analysis may be advicable (large leaks are easier to
> locate as well).


Am I the only one who thinks this is terrible advice?

-- 
Real (i.e. statistical) tennis and snooker player rankings and ratings:
http://www.statsfair.com/ 

[toc] | [prev] | [next] | [standalone]

#48032

[Multipart message — attachments visible in raw view] — view raw

Giorgos Tzampanakis <giorgos.tzampanakis@gmail.com> wrote:

>On 2013-06-13, dieter wrote:
>
>>> ...  Anyway, my real question is how to go about debugging memory
>leak
>>> problems in Python, particularly for a long running server process
>>> written with Twisted. I'm not sure how to use heapy or guppy, and
>>> objgraph doesn't tell me enough to locate the problem.
>>
>> Analysing memory leaks is really difficult: huge amounts of data is
>> involved and usually, it is almost impossible to determine which of
>the
>> mentioned objects are leaked and which are rightfully in use.  In
>> addition, long running Python processes usually have degrading memory
>> use - due to memory fragmentation. There is nothing you can do
>against
>> this.
>>
>> Therefore: if the leak seems to be small, it may be much more
>advicable
>> to restart your process periodically (during times where a restart
>does
>> not hurt much) rather than try to find (and fix) the leaks. Only when
>> the leak is large enough that it would force you to too frequent
>> restarts, a deeper analysis may be advicable (large leaks are easier
>to
>> locate as well).
>
>
>Am I the only one who thinks this is terrible advice?
>
>-- 
>Real (i.e. statistical) tennis and snooker player rankings and ratings:
>http://www.statsfair.com/ 
>-- 
>http://mail.python.org/mailman/listinfo/python-list

No you are not alone.  Ignoring a bug is only sensible if you absolutely understand what is going wrong - and by the time you understand the problem that well, you probably have enough understanding to fix it.  If tools are available (as the OP knows), then learn them and use them to find/fix the bug. 
Steve S

Sent from a Galaxy far far away

[toc] | [prev] | [next] | [standalone]

#48037

On Fri, Jun 14, 2013 at 6:15 AM, Giorgos Tzampanakis
<giorgos.tzampanakis@gmail.com> wrote:
> On 2013-06-13, dieter wrote:
>> Therefore: if the leak seems to be small, it may be much more advicable
>> to restart your process periodically (during times where a restart does
>> not hurt much) rather than try to find (and fix) the leaks. Only when
>> the leak is large enough that it would force you to too frequent
>> restarts, a deeper analysis may be advicable (large leaks are easier to
>> locate as well).
>
>
> Am I the only one who thinks this is terrible advice?

Definitely not alone there, but I'm biased; I like to keep systems and
processes running for ridiculous lengths of time. Up until we suffered
a simultaneous UPS failure and power outage, I had one process still
running from shortly after the system had been booted... over two
years previously. (That same program now has 20 weeks+ of uptime.)
Granted, that would be impractical in Python, since it's not easy to
edit code of a live system; but still, once your code is stable, you
wouldn't be restarting for that, and your uptime figures should be
able to reflect that.

ChrisA

[toc] | [prev] | [next] | [standalone]

#48049

On Thu, 13 Jun 2013 20:15:42 +0000, Giorgos Tzampanakis wrote:

>> Therefore: if the leak seems to be small, it may be much more advicable
>> to restart your process periodically (during times where a restart does
>> not hurt much) rather than try to find (and fix) the leaks. Only when
>> the leak is large enough that it would force you to too frequent
>> restarts, a deeper analysis may be advicable (large leaks are easier to
>> locate as well).
> 
> 
> Am I the only one who thinks this is terrible advice?


Sub-optimal, maybe, but terrible? Not even close. Terrible advice would 
be "open up all the ports on your firewall, that will fix it!"

If it takes, say, 200 person-hours to track down this memory leak, and 
another 200 person-hours to fix it, that's an awful large expense. In 
that case, it would surely be better to live with the inconvenience and 
mess of having a nightly/weekly/monthly reboot. On the other hand, maybe 
it will only take 1 hour to find, and fix, the leak. Who knows?

My advice is to give yourself a deadline:

"If I have not found the leak in one week, or found and fixed it in three 
weeks, then I'll probably never fix it and I should just give up and 
apply palliative reboots to work around the problem."

Either that or hire an expert at debugging memory leaks.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#48101

On Fri, Jun 14, 2013 at 12:40 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Thu, 13 Jun 2013 20:15:42 +0000, Giorgos Tzampanakis wrote:
>
>>> Therefore: if the leak seems to be small, it may be much more advicable
>>> to restart your process periodically (during times where a restart does
>>> not hurt much) rather than try to find (and fix) the leaks. Only when
>>> the leak is large enough that it would force you to too frequent
>>> restarts, a deeper analysis may be advicable (large leaks are easier to
>>> locate as well).
>>
>>
>> Am I the only one who thinks this is terrible advice?
> Sub-optimal, maybe, but terrible? Not even close. Terrible advice would
> be "open up all the ports on your firewall, that will fix it!"
>...
>
> My advice is to give yourself a deadline:
>
> "If I have not found the leak in one week, or found and fixed it in three
> weeks, then I'll probably never fix it and I should just give up and
> apply palliative reboots to work around the problem."
>
> Either that or hire an expert at debugging memory leaks.

It's terrible advice in generality, because it encourages a sloppiness
of thinking: "Memory usage doesn't matter, we'll just instruct people
to reset everything now and then". When you have a problem on your
hands, you always have to set a deadline [1] but sometimes you have to
set the deadline the other way, too: "I'll just reboot it now, but if
it runs out of memory within a week, I *have* to find the problem".
Also, I think everyone should have at least one shot at a project that
has to stay up for multiple months, preferably a year. Even if you
never actually achieve a whole year of uptime, *think* that way. It'll
help you get things into perspective: "If I were running this all
year, that might be an issue, but who cares about a memory leak in a
script that's going to be finished in an hour!".

[1] cf http://www.gnu.org/fun/jokes/last.bug.html

ChrisA

[toc] | [prev] | [next] | [standalone]

#48220

On 2013-06-14, Steven D'Aprano wrote:

> On Thu, 13 Jun 2013 20:15:42 +0000, Giorgos Tzampanakis wrote:
>
>>> Therefore: if the leak seems to be small, it may be much more advicable
>>> to restart your process periodically (during times where a restart does
>>> not hurt much) rather than try to find (and fix) the leaks. Only when
>>> the leak is large enough that it would force you to too frequent
>>> restarts, a deeper analysis may be advicable (large leaks are easier to
>>> locate as well).
>> 
>> 
>> Am I the only one who thinks this is terrible advice?
>
>
> Sub-optimal, maybe, but terrible? Not even close. Terrible advice would 
> be "open up all the ports on your firewall, that will fix it!"
>
> If it takes, say, 200 person-hours to track down this memory leak, and 
> another 200 person-hours to fix it, that's an awful large expense. In 
> that case, it would surely be better to live with the inconvenience and 
> mess of having a nightly/weekly/monthly reboot. On the other hand, maybe 
> it will only take 1 hour to find, and fix, the leak. Who knows?

But having a memory leak in the first place is an indication that
something is very wrong with your program. Either you're keeping
references that you didn't mean to be keeping (which indicates that there
can be larger side-effects than just wasted memory) or a linked C library
is leaking memory, which is bad for reasons which I won't cover here since
they are self-evident.


-- 
Real (i.e. statistical) tennis and snooker player rankings and ratings:
http://www.statsfair.com/ 

[toc] | [prev] | [next] | [standalone]

#48240

On Fri, 14 Jun 2013 22:57:24 +0000, Giorgos Tzampanakis wrote:

> On 2013-06-14, Steven D'Aprano wrote:
> 
>> On Thu, 13 Jun 2013 20:15:42 +0000, Giorgos Tzampanakis wrote:
>>
>>>> Therefore: if the leak seems to be small, it may be much more
>>>> advicable to restart your process periodically (during times where a
>>>> restart does not hurt much) rather than try to find (and fix) the
>>>> leaks. Only when the leak is large enough that it would force you to
>>>> too frequent restarts, a deeper analysis may be advicable (large
>>>> leaks are easier to locate as well).
>>> 
>>> 
>>> Am I the only one who thinks this is terrible advice?
>>
>>
>> Sub-optimal, maybe, but terrible? Not even close. Terrible advice would
>> be "open up all the ports on your firewall, that will fix it!"
>>
>> If it takes, say, 200 person-hours to track down this memory leak, and
>> another 200 person-hours to fix it, that's an awful large expense. In
>> that case, it would surely be better to live with the inconvenience and
>> mess of having a nightly/weekly/monthly reboot. On the other hand,
>> maybe it will only take 1 hour to find, and fix, the leak. Who knows?
> 
> But having a memory leak in the first place is an indication that
> something is very wrong with your program. Either you're keeping
> references that you didn't mean to be keeping (which indicates that
> there can be larger side-effects than just wasted memory) or a linked C
> library is leaking memory, which is bad for reasons which I won't cover
> here since they are self-evident.

You mean a bug in your code is a sign that there is a bug in your code? 
Who would have imagined! *wink*

Of course you are right that a memory leak is a bug. And like all bugs, 
ideally you will want to fix it. But sometimes bugs are too difficult to 
fix, and the inconvenience of restarting the app too minor to care. For 
many applications, "restart once a month" is no big deal, especially 
compared to "spend three months trying to track down this one bug, 
instead of doing work that will actually pay the bills".

I'm not suggesting that living with a memory leak is *in and of itself* a 
good thing, only that sometimes there are higher priorities.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#48260

Chris Angelico <rosuav@gmail.com> writes:

> ...
> It's terrible advice in generality, because it encourages a sloppiness
> of thinking: "Memory usage doesn't matter, we'll just instruct people
> to reset everything now and then".

"Memory usage" may matter. But if you loose 1 kb a day, your process
can run 3 years before you have lost 1 MB. Compare this to the
485 MB used when you start "firefox". The situation looks different
when you loose 10 MB a day.

[toc] | [prev] | [next] | [standalone]

#48263

On Sat, Jun 15, 2013 at 4:52 PM, dieter <dieter@handshake.de> wrote:
> Chris Angelico <rosuav@gmail.com> writes:
>
>> ...
>> It's terrible advice in generality, because it encourages a sloppiness
>> of thinking: "Memory usage doesn't matter, we'll just instruct people
>> to reset everything now and then".
>
> "Memory usage" may matter. But if you loose 1 kb a day, your process
> can run 3 years before you have lost 1 MB. Compare this to the
> 485 MB used when you start "firefox". The situation looks different
> when you loose 10 MB a day.

Right. Everything needs to be scaled. Everything needs to be in
perspective. Losing 1 kilobit per day is indeed trivial; even losing
one kilobyte per day, which is what I assume you meant :), isn't
significant. But it's not usually per day, it's per leaking action.
Suppose your web browser leaks 1024 usable bytes of RAM every HTTP
request. Do you know how much that'll waste per day? CAN you know?

ChrisA

[toc] | [prev] | [next] | [standalone]

#48414

Chris Angelico <rosuav@gmail.com> writes:
> ...
> Right. Everything needs to be scaled. Everything needs to be in
> perspective. Losing 1 kilobit per day is indeed trivial; even losing
> one kilobyte per day, which is what I assume you meant :), isn't
> significant. But it's not usually per day, it's per leaking action.
> Suppose your web browser leaks 1024 usable bytes of RAM every HTTP
> request. Do you know how much that'll waste per day? CAN you know?

What I suggested to the original poster was that *he* checks
whether *his* server leaks a really significant amount of memory
-- and starts to try a (difficult) memory leak analysis only in this
case. If he can restart his server periodically, this may make
the analysis unnecessary.

I also reported that I have undertaken such an analysis several times and
what helped me in these cases. I know - by experience - how difficult 
those analysis are. And there have been cases, where I failed despite
much effort: the systems I work with are huge, consisting of
thousands of components, developed by various independent groups,
using different languages (Python, C, Java); each of those components
may leak memory; most components are "foreign" to me.
Surely, you understand that in such a context a server restart
in the night of a week end (leading to a service disruption of a
few seconds) seems an attractive alternative to trying to locate the leaks.

Things would change drastically if the leak is big enough to force a restart
every few hours. But big leaks are *much* easier to detect
and locate than small leaks.

[toc] | [prev] | [next] | [standalone]

#48149

On Jun 14, 1:15 am, Giorgos Tzampanakis
<giorgos.tzampana...@gmail.com> wrote:
> Am I the only one who thinks this is terrible advice?

I would expect a typical desktop app to run for a couple of hours --
maybe a couple of days.
Living with a small (enough) leak there may be ok.
[In particular I believe that most commercial apps will leak a bit if
run long enough]

The case of something server-ish is quite different.
A server in principle runs forever.
And so if it leaks its not working.

[toc] | [prev] | [next] | [standalone]

#48228

On Fri, Jun 14, 2013 at 11:53 PM, rusi <rustompmody@gmail.com> wrote:
> On Jun 14, 1:15 am, Giorgos Tzampanakis
> <giorgos.tzampana...@gmail.com> wrote:
>> Am I the only one who thinks this is terrible advice?
>
> I would expect a typical desktop app to run for a couple of hours --
> maybe a couple of days.
> Living with a small (enough) leak there may be ok.
> [In particular I believe that most commercial apps will leak a bit if
> run long enough]
>
> The case of something server-ish is quite different.
> A server in principle runs forever.
> And so if it leaks its not working.

I keep my clients running for months. My Windows laptop (let's not
even get started on my Linux boxes) got rebooted a few weeks ago
(can't remember why), but I've had it running for two months or more
at a time. And that's Windows XP, not the most stable OS ever
invented, and a computer that's used fairly constantly - two web
browsers, a MUD client that retains full history, music/movie playing
with VLC, SciTE, IDLE, BitTorrent, and a bunch of other stuff. And I
don't reboot it; I don't even restart applications if I can help it
(except VLC, I tend to close that when I'm done). Any memory leak in
any of the apps I use would be highly visible and extremely annoying;
and there *were* such leaks in the Flash players of yesterday.
Fortunately now I can leave browsers running constantly. (Either that,
or the plugins container gets restarted. Not sure.)

Just because it's a client doesn't mean it can't be treated seriously. :)

Of course, my style IS unusual. Most people don't do what I do.

ChrisA

[toc] | [prev] | [next] | [standalone]

#48230

rusi <rustompmody@gmail.com> writes:

> On Jun 14, 1:15 am, Giorgos Tzampanakis
> <giorgos.tzampana...@gmail.com> wrote:
> > Am I the only one who thinks this is terrible advice?
>
> I would expect a typical desktop app to run for a couple of hours --
> maybe a couple of days.

Is a web browser a “typical desktop app”? A filesystem browser? An
instant messenger? A file transfer application? A podcatcher? All of
those typically run for months at a time on my desktop.

Any memory leak in any of those is going to cause trouble, please hunt
them all down with fire and exterminate with prejudice.

-- 
 \             “Experience is that marvelous thing that enables you to |
  `\   recognize a mistake when you make it again.” —Franklin P. Jones |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#48246

On Jun 15, 5:16 am, Ben Finney <ben+pyt...@benfinney.id.au> wrote:
> rusi <rustompm...@gmail.com> writes:
> > On Jun 14, 1:15 am, Giorgos Tzampanakis
> > <giorgos.tzampana...@gmail.com> wrote:
> > > Am I the only one who thinks this is terrible advice?
>
> > I would expect a typical desktop app to run for a couple of hours --
> > maybe a couple of days.
>
> Is a web browser a “typical desktop app”? A filesystem browser? An
> instant messenger? A file transfer application? A podcatcher? All of
> those typically run for months at a time on my desktop.
>
> Any memory leak in any of those is going to cause trouble, please hunt
> them all down with fire and exterminate with prejudice.

Oh well -- I guess I am an old geezer who shuts my machine when I am
done!
Yeah I know -- not so good for the disk though its good for the
planet!

[toc] | [prev] | [next] | [standalone]

#48284

rusi <rustompmody@gmail.com> writes:

> On Jun 15, 5:16 am, Ben Finney <ben+pyt...@benfinney.id.au> wrote:
> > Is a web browser a “typical desktop app”? A filesystem browser? An
> > instant messenger? A file transfer application? A podcatcher? All of
> > those typically run for months at a time on my desktop.
> >
> > Any memory leak in any of those is going to cause trouble, please
> > hunt them all down with fire and exterminate with prejudice.
>
> Oh well -- I guess I am an old geezer who shuts my machine when I am
> done!

As do I. And when I power on the machine, it resumes exactly where it
left off: with the exact same contents of memory as when I pressed the
Suspend button.

That is, the memory leak will continue to accumulate as the run time of
the process continues.

> Yeah I know -- not so good for the disk though its good for the
> planet!

You can have both: a continuous session, and stop consuming power while
not using your machine.

-- 
 \     “It is far better to grasp the universe as it really is than to |
  `\    persist in delusion, however satisfying and reassuring.” —Carl |
_o__)                                                            Sagan |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#48287

On Jun 15, 4:23 pm, Ben Finney <ben+pyt...@benfinney.id.au> wrote:
> rusi <rustompm...@gmail.com> writes:
> > On Jun 15, 5:16 am, Ben Finney <ben+pyt...@benfinney.id.au> wrote:
> > > Is a web browser a “typical desktop app”? A filesystem browser? An
> > > instant messenger? A file transfer application? A podcatcher? All of
> > > those typically run for months at a time on my desktop.
>
> > > Any memory leak in any of those is going to cause trouble, please
> > > hunt them all down with fire and exterminate with prejudice.
>
> > Oh well -- I guess I am an old geezer who shuts my machine when I am
> > done!
>
> As do I. And when I power on the machine, it resumes exactly where it
> left off: with the exact same contents of memory as when I pressed the
> Suspend button.
>
> That is, the memory leak will continue to accumulate as the run time of
> the process continues.
>
> > Yeah I know -- not so good for the disk though its good for the
> > planet!
>
> You can have both: a continuous session, and stop consuming power while
> not using your machine.

Suspend is low-power, hibernate is 0-power
http://www.unixmen.com/suspend-vs-hibernate-in-linux-what-is-the-difference/

And I keep having some issues with hibernate

[toc] | [prev] | [next] | [standalone]

#48288

On Sat, Jun 15, 2013 at 9:35 PM, rusi <rustompmody@gmail.com> wrote:
> On Jun 15, 4:23 pm, Ben Finney <ben+pyt...@benfinney.id.au> wrote:
>> rusi <rustompm...@gmail.com> writes:
>> > On Jun 15, 5:16 am, Ben Finney <ben+pyt...@benfinney.id.au> wrote:
>> > > Is a web browser a “typical desktop app”? A filesystem browser? An
>> > > instant messenger? A file transfer application? A podcatcher? All of
>> > > those typically run for months at a time on my desktop.
>>
>> > > Any memory leak in any of those is going to cause trouble, please
>> > > hunt them all down with fire and exterminate with prejudice.
>>
>> > Oh well -- I guess I am an old geezer who shuts my machine when I am
>> > done!
>>
>> As do I. And when I power on the machine, it resumes exactly where it
>> left off: with the exact same contents of memory as when I pressed the
>> Suspend button.
> Suspend is low-power, hibernate is 0-power
> http://www.unixmen.com/suspend-vs-hibernate-in-linux-what-is-the-difference/
>
> And I keep having some issues with hibernate

You can configure the Suspend button to hibernate the computer. Though
my personal preference, when hibernating a computer, is to trigger it
directly from software. Anyway, same difference; shut down a computer
without shutting down a process. I do the same with several of my VMs
- when I'm done with them, Save Machine State. (Except the one for
Magic: The Gathering Online. For some reason MTGO has problems if I
don't actually reboot it periodically, so that one I just shut down.)

ChrisA

[toc] | [prev] | [next] | [standalone]

#48001

Dieter,

Thanks for the response, and you're correct, debugging memory leaks is tough! So far I haven't had much luck other than determining I have a leak. I've used objgraph to see that objects are being created that don't seem to get cleaned up. What I can't figure out so far is why, they are local variable objects that "should" get cleaned up when they go out scope.

Ah well, I'll keep pushing!
Thanks again,
Doug

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web