* [sup-talk] sup-sync dies; memory limit?
@ 2009-05-08 16:42 Andrew Pimlott
2009-05-11 18:26 ` Andrew Pimlott
0 siblings, 1 reply; 5+ messages in thread
From: Andrew Pimlott @ 2009-05-08 16:42 UTC (permalink / raw)
I have been running sup-sync on a new mailbox, and it tends to get
partway through and then die, but not in the same place each time.
Twice, the error has been like
/var/lib/gems/1.8/gems/sup-0.7/lib/sup/crypto.rb:162:in ``': Cannot allocate memory - /usr/bin/gpg --quiet --batch --no-verbose --logger-fd 1 --use-agent --verify /tmp/28751-0-redwood.signature /tmp/28751-0-redwood.payload 2> /dev/null (Errno::ENOMEM)
followed by a backtrace. Another time, it was just
zsh: killed /var/lib/gems/1.8/bin/sup-sync --all-sources
I monitored the sup-sync process the last time. It's memory use grew
slowly, and the process died at around 64M of virtual memory. I don't
have any memory limits set. Is it possible that sup-sync or ruby uses
some itself? Any other ideas?
Andrew
^ permalink raw reply [flat|nested] 5+ messages in thread
* [sup-talk] sup-sync dies; memory limit?
2009-05-08 16:42 [sup-talk] sup-sync dies; memory limit? Andrew Pimlott
@ 2009-05-11 18:26 ` Andrew Pimlott
2009-05-12 17:19 ` William Morgan
0 siblings, 1 reply; 5+ messages in thread
From: Andrew Pimlott @ 2009-05-11 18:26 UTC (permalink / raw)
I forgot to mention, this was the latest release (0.7) installed with
gem. I just tried the current git mainline (clearing all my .sup state
first), and it got through my whole mailbox without a problem.
Andrew
On Fri, May 08, 2009 at 09:42:26AM -0700, Andrew Pimlott wrote:
> I have been running sup-sync on a new mailbox, and it tends to get
> partway through and then die, but not in the same place each time.
> Twice, the error has been like
>
> /var/lib/gems/1.8/gems/sup-0.7/lib/sup/crypto.rb:162:in ``': Cannot allocate memory - /usr/bin/gpg --quiet --batch --no-verbose --logger-fd 1 --use-agent --verify /tmp/28751-0-redwood.signature /tmp/28751-0-redwood.payload 2> /dev/null (Errno::ENOMEM)
>
> followed by a backtrace. Another time, it was just
>
> zsh: killed /var/lib/gems/1.8/bin/sup-sync --all-sources
>
> I monitored the sup-sync process the last time. It's memory use grew
> slowly, and the process died at around 64M of virtual memory. I don't
> have any memory limits set. Is it possible that sup-sync or ruby uses
> some itself? Any other ideas?
>
> Andrew
> _______________________________________________
> sup-talk mailing list
> sup-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 5+ messages in thread
* [sup-talk] sup-sync dies; memory limit?
2009-05-11 18:26 ` Andrew Pimlott
@ 2009-05-12 17:19 ` William Morgan
2009-05-12 18:31 ` Andrew Pimlott
0 siblings, 1 reply; 5+ messages in thread
From: William Morgan @ 2009-05-12 17:19 UTC (permalink / raw)
Reformatted excerpts from Andrew Pimlott's message of 2009-05-11:
> On Fri, May 08, 2009 at 09:42:26AM -0700, Andrew Pimlott wrote:
> > I don't have any memory limits set. Is it possible that sup-sync or
> > ruby uses some itself? Any other ideas?
Very mysterious. Sup-sync doesn't do anything fancy with memory; it's a
fairly straight-forward Ruby script. Maybe one of the C extensions (like
Ferret) has a memory leak.
> I forgot to mention, this was the latest release (0.7) installed with
> gem. I just tried the current git mainline (clearing all my .sup
> state first), and it got through my whole mailbox without a problem.
Evey more mysterious. The differences between these two versions are
trivial:
diff --git a/origin/release-0.7:bin/sup-sync b/origin/master:bin/sup-sync
index ac5caf6..91710d4 100644
--- a/origin/release-0.7:bin/sup-sync
+++ b/origin/master:bin/sup-sync
@@ -143,12 +143,7 @@ begin
next if target == :changed && entry && entry[:source_id].to_i == source.id && entry[:source_info].to_i == offset
## get the state currently in the index
- index_state =
- if entry
- entry[:label].split(/\s+/).map { |x| x.intern }
- else
- nil
- end
+ index_state = entry[:label].split(/\s+/).map { |x| x.intern } if entry
## skip if we're operating on restored messages, and this one
## ain't.
@@ -163,7 +158,7 @@ begin
## assign message labels based on the operation we're performing
case op
when :asis
- m.labels = index_state if index_state
+ m.labels = ((m.labels - [:unread, :inbox]) + index_state).uniq if index_state
when :restore
## if the entry exists on disk
if restored_state[m.id]
I'm at a loss.
--
William <wmorgan-sup at masanjin.net>
^ permalink raw reply [flat|nested] 5+ messages in thread* [sup-talk] sup-sync dies; memory limit?
2009-05-12 17:19 ` William Morgan
@ 2009-05-12 18:31 ` Andrew Pimlott
2009-05-12 19:54 ` William Morgan
0 siblings, 1 reply; 5+ messages in thread
From: Andrew Pimlott @ 2009-05-12 18:31 UTC (permalink / raw)
On Tue, May 12, 2009 at 10:19:48AM -0700, William Morgan wrote:
> Reformatted excerpts from Andrew Pimlott's message of 2009-05-11:
> > On Fri, May 08, 2009 at 09:42:26AM -0700, Andrew Pimlott wrote:
> > > I don't have any memory limits set. Is it possible that sup-sync or
> > > ruby uses some itself? Any other ideas?
>
> Very mysterious.
I cannot reproduce the problem anymore, but as far as I know, nothing
changed on my system (other than the inbox I am testing with evolving
routinely). sup-sync from the 0.7 gem now runs to completion and never
uses more than ~36M virtual memory (before it got up around 60M before
crashing). It doesn't seem possible that the git copy of sup affected
the installed gem. So I'm at a complete loss too.
Andrew
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-05-12 19:54 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-05-08 16:42 [sup-talk] sup-sync dies; memory limit? Andrew Pimlott
2009-05-11 18:26 ` Andrew Pimlott
2009-05-12 17:19 ` William Morgan
2009-05-12 18:31 ` Andrew Pimlott
2009-05-12 19:54 ` William Morgan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox