On 02/01/2014 03:07 PM, walt wrote:
> This is from git 7161f501, but the crash can take 15-30 minutes to happen, so
> bisecting
> it is a bit dicey. I'll bisect my way through this, but that will take some
> time:
<big snip>
Okay, I posted earlier that the problem commit was this one:
commit 35bf10f456956da19a39d5b5d8bbf3f84dffcb80
Author: Heinrich Müller <henm...@src.gnome.org>
Date: Wed Nov 20 21:19:00 2013 +0100
cleanup of experimental code
But that was a very big commit, so I had to puzzle out which part of it caused
the segfaults,
which I finally did today (94% confidence :)
It was this one-liner:
commit 35bf10f456956da19a39d5b5d8bbf3f84dffcb80
Author: Heinrich Müller <henm...@src.gnome.org>
Date: Wed Nov 20 21:19:00 2013 +0100
cleanup of experimental code
diff --git a/pan/data/article-cache.cc b/pan/data/article-cache.cc
index d6cb747..0ac3d57 100644
--- a/pan/data/article-cache.cc
+++ b/pan/data/article-cache.cc
@@ -120,6 +120,7 @@ ArticleCache :: message_id_to_filename (char * buf, int
len, const StringView& m
break;
default:
*out++ = *in;
+ break;
}
}
That patch concerns the handling of malformed articles, so it makes sense that
my segfaults are rare (possibly an hour or so of downloading articles).
Anyway, I reverted that one-liner and pan has been running happily (from a
command
prompt) for over an hour without any warnings or asserts. That's 100%
improvement
over a dozen or more critical asserts in the first 15 minutes involving
g_object_ref
and g_object_unref.
I'll let pan run overnight to increase my confidence level to 99% and post the
result.
_______________________________________________
Pan-users mailing list
Pan-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/pan-users
