pan-users
[Top][All Lists]
Advanced

[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.






reply via email to

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