On Wed 19 Feb 2014 at 17:20:06 -0800, walt wrote:
> Hi Olaf, and thanks for taking the time to inspect the code. I should
> add that I didn't come up with that patch based on my brilliant coding
> skills :)
>
> What I'm doing is inspecting Heinrich's commit
>
> commit 35bf10f456956da19a39d5b5d8b
On 02/19/2014 03:51 PM, Rhialto wrote:
> On Tue 18 Feb 2014 at 16:01:04 -0800, walt wrote:
>> My theory ATM is that there are at least two different bugs bugging me :)
>>
>> The crash caused by the article above *may* be fixed by the change below:
>>
>> diff --git a/pan/data/article-cache.cc b/pan/
On Tue 18 Feb 2014 at 16:01:04 -0800, walt wrote:
> My theory ATM is that there are at least two different bugs bugging me :)
>
> The crash caused by the article above *may* be fixed by the change below:
>
> diff --git a/pan/data/article-cache.cc b/pan/data/article-cache.cc
> index 0ac3d57..53750
On 02/17/2014 07:03 PM, Duncan wrote:
> walt posted on Mon, 17 Feb 2014 18:31:29 -0800 as excerpted:
>
>> 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
walt posted on Mon, 17 Feb 2014 18:31:29 -0800 as excerpted:
> 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.
FWIW...
I
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:
>
>
>
> Okay, I posted earlier that t
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:
Okay, I posted earlier that the problem commit was this one:
commit 35bf10f456
walt posted on Thu, 13 Feb 2014 15:29:51 -0800 as excerpted:
> Duncan: I installed 'duma' and I'm still trying to make it through the
> man page :) I just don't know enough (yet) to understand it. Any hints
> would be most welcome.
I don't have any to give, as I've not used it. =:^( All I kno
On 02/03/2014 02:33 PM, Zan Lynx wrote:
> On Sun, Feb 2, 2014 at 3:26 PM, walt wrote:
>> Starting program: /home/wa1ter/bin/pan.35b
>> warning: Could not load shared library symbols for linux-vdso.so.1.
>> Do you need "set solib-search-path" or "set sysroot"?
>> [Thread debugging using libthread_d
Paul Crawford posted on Wed, 05 Feb 2014 01:39:03 + as excerpted:
> On 04/02/14 01:01, walt wrote:
>> I've been looking for electric fence (efence) and running into 404's
>> everywhere. Valgrind is easily available, so I'll try to learn how to
>> use it -- results not guaranteed :)
>
> Reall
Just to add, for debugging you might also want to set optimisation off
(for example "-O0" compiler flag) and make sure debug symbols are
enabled (for example with the "-g" compiler flag).
That way you can stop through the machine code with some degree of
resemblance to the source code!
Regar
On 04/02/14 01:01, walt wrote:
I've been looking for electric fence (efence) and running into 404's
everywhere. Valgrind is easily available, so I'll try to learn how
to use it -- results not guaranteed :)
Really? On a typical Debian machine (like Ubuntu) you just install the
library with:
On 02/03/2014 02:33 PM, Zan Lynx wrote:
> On Sun, Feb 2, 2014 at 3:26 PM, walt
> wrote:
>> Starting program: /home/wa1ter/bin/pan.35b
>> warning: Could not load shared library symbols for linux-vdso.so.1.
>> Do you need "set solib-search-path" or "set sysroot"?
>> [Thread debugging using libthr
On Sun, Feb 2, 2014 at 3:26 PM, walt wrote:
> Starting program: /home/wa1ter/bin/pan.35b
> warning: Could not load shared library symbols for linux-vdso.so.1.
> Do you need "set solib-search-path" or "set sysroot"?
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "
On 02/02/2014 03:00 PM, Paul Crawford wrote:
> On 02/02/14 22:26, walt wrote:
>> [New Thread 0x7fffe7fff700 (LWP 21954)] [New Thread 0x7fffe4c98700
>> (LWP 21957)] *** Error in `/home/wa1ter/bin/pan.35b': corrupted
>> double-linked list: 0x17d84e70 ***
>>
>> That was all there was -- no b
On 02/02/14 22:26, walt wrote:
[New Thread 0x7fffe7fff700 (LWP 21954)]
[New Thread 0x7fffe4c98700 (LWP 21957)]
*** Error in `/home/wa1ter/bin/pan.35b': corrupted double-linked list:
0x17d84e70 ***
That was all there was -- no backtrace was available.
If you are getting problems relat
This is from:
commit 35bf10f456956da19a39d5b5d8bbf3f84dffcb80
Author: Heinrich Müller
Date: Wed Nov 20 21:19:00 2013 +0100
cleanup of experimental code
hence I renamed the executable pan.35b before running it. Pan.35b ran for
for about an hour before crashing with the following message,
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:
>
> (BTW, the traces vary a bit, but every trace includes gnutls (v3.2.9))
This
18 matches
Mail list logo
