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:
<snip>
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
Aborted
Tue Mar 29 01:27:17 CDT 2011
That sounds like it ran out of memory.
Exactly.
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
barfs.
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
elements.
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.
Paul
_______________________________________________
Pan-users mailing list
Pan-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/pan-users
