Re: Bug#245678: zsh: built-in rm -rf fills up the memory

[Bart Schaefer <schaefer@brasslantern.com>]

On Apr 24,  9:36pm, Clint Adams wrote:
}
} I can reproduce the memory consumption with a 7210-file Maildir, except
} that my kernel does the right thing and kills the runaway zsh.
} 
} If I abort the rm before it OOMs, zsh will continue to take up a large
} amount of memory until it exits.

There's got to be something here you're not telling us.  Either there is
an alias for "rm", or a function named "rm", or the zsh/files module is
loaded; otherwise "rm" and "/bin/rm" should be equivalent (assuming there
is no other "rm" in the path) and in any case shouldn't execute inside
the shell.

Assuming that it's the zsh/files module, the interesting thing there is
that, because it's a depth-first traversal, it allocates zsh-heap memory
to store all the file names in the directory, and it does so by growing
the allocated heap block once for each filename, by the length of that
filename (plus one).  If ZSH_MEM was not defined at compile time, doing
this efficiently is left up to the underlying malloc() implementation [if
I'm reading mem.c correctly] and therefore could be subject to bugs we've
seen before where malloc never reclaims nor consolidates blocks when the
implementation repeatedly realloc()s in slightly larger chunks.

I don't know anything about how zsh is compiled on debian or even why
the zsh/files module would be used (seemingly) by default, but in that's
probably the place to start looking.