monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] "memory exhausted" error for 'mtn list status' comm


From: Drakie Awita
Subject: Re: [Monotone-devel] "memory exhausted" error for 'mtn list status' command
Date: Fri, 28 Jul 2006 21:56:36 -0700

Nathaniel:

No, I'm not using Reiser FS; it happens on both ext3 FS (debian
linux), and NTFS (Windows XP).

I've found that, if I move the large un-versioned sub-directory
(contrib/oss.boost.release) out of the project root dir, then 'mtn
list unknown' works ok.  So it looks like the problem is related to
the "path-walking" code you mentioned.  One quick test you might try
to reproduce this problem is to download and untar boost_1_33_1.tar.gz
inside your mtn project directory, and do a 'mtn list unknown'.

Thanks for your reply; I'll try pull your fixes later.

--- Drakie

On 7/28/06, Nathaniel Smith <address@hidden> wrote:
On Wed, Jul 26, 2006 at 07:09:23PM -0700, Drakie Awita wrote:
> Hi,
>
> I've been a happy mtn user for a while, and the upgrade to v0.27 is ok
> except for one problem: if I have some large amount of un-versioned
> files/sub-directories (thousands of them) under my versioned project
> tree, then 'mtn list unknow' command errors out with "memory
> exhausted" message:
>
> # mtn list unknown
> mtn: fatal: std::runtime_error: Memory exhausted
> mtn:
> mtn: this is almost certainly a bug in monotone.
> mtn: please send this error message, the output of 'mtn --full-version',
> mtn: and a description of what you were doing to address@hidden
> mtn: wrote debugging log to ....../_MTN/debug
> mtn: if reporting a bug, please include this file

Are you using reiserfs, by chance?  Some bad interaction between
reiserfs, glibc, and our path walking code caused it to take up rather
a lot of memory before monotone revision 6c0bb3dfda5f24ce59 (which I
just committed).

The ignore file doesn't matter here, because at the moment we don't
have separate code to scan for unknown and ignored files; instead, we
always scan for both, and then print only one or both lists.  Possibly
we should change that too, but first it would be good to know if my
previous patch helps?

-- Nathaniel

--
.i dei jitfa fanmo xatra





reply via email to

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