[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Pan-users] Re: Feature request: CLI operation

From: Paul Crawford
Subject: Re: [Pan-users] Re: Feature request: CLI operation
Date: Tue, 29 Mar 2011 09:35:51 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110223 Thunderbird/3.1.8

On 29/03/11 09:09, Ron Johnson wrote:
On 03/29/2011 02:12 AM, Paul Crawford wrote:
On 29/03/11 07:33, Ron Johnson wrote:
5 hours...

$ date && pan --no-gui headers:alt.binaries.dvd ; date
Mon Mar 28 20:25:33 CDT 2011
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
Tue Mar 29 01:27:17 CDT 2011

That sounds like it ran out of memory.


Are you running 32-bit or 64-bit,
and what are your machine's limits (RAM & swap space)?

It's 32-bit. Running "top" clearly shows pan's memory usage (RES)
growing and growing. At about 3GB (a processes' address space in x86) it

Well we know now what it is!

Do you have a 64-bit CPU machine (e.g. I do, but run 32-bit Linux for greater compatibility and due to only have 2GB RAM)?

If so you could boot off a 64-bit live CD, set enough swap space and just let it crunch away.

Of course it might be a bug/design flaw where a list grows
larger/quicker than it really needs to for the element size & number of

Not a bug per se, but a consequence of the design decision to fetch all
of a group's headers into RAM before flushing them to disk. Never
occurred to them that a News provider would retain all messages.

Yes, what seemed like a good enough idea at the time.

Funny how a decade ago it seemed like virtually nothing would need more than 32-bit address space, and now we can find something like reading a news group where the only _simple_ solution is to use the 64-bit address version.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]