[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pan-users] Segfaults from recent pan2.git [crap, NOTSOLVED]
From: |
walt |
Subject: |
Re: [Pan-users] Segfaults from recent pan2.git [crap, NOTSOLVED] |
Date: |
Mon, 17 Feb 2014 18:31:29 -0800 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 |
On 02/17/2014 06:08 PM, walt wrote:
> 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 <address@hidden>
> 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 <address@hidden>
> 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.
A few minutes after I posted, pan segfaulted again with the usual backtrace
involving
gnutls, so I'll start over. But there were no asserts involving
g_object_ref/unref, so
maybe there are two separate bugs? Dunno.
Re: [Pan-users] Segfaults from recent pan2.git [SOLVED?], walt, 2014/02/17
- Re: [Pan-users] Segfaults from recent pan2.git [crap, NOTSOLVED],
walt <=
- Re: [Pan-users] Segfaults from recent pan2.git [crap, NOTSOLVED], Duncan, 2014/02/17
- Re: [Pan-users] Segfaults from recent pan2.git [crap, NOTSOLVED], walt, 2014/02/18
- Re: [Pan-users] Segfaults from recent pan2.git [crap, NOTSOLVED], Rhialto, 2014/02/19
- Re: [Pan-users] Segfaults from recent pan2.git [crap, NOTSOLVED], walt, 2014/02/19
- Re: [Pan-users] Segfaults from recent pan2.git [crap, NOTSOLVED], Rhialto, 2014/02/20