[Pan-users] BUG 0.94 (and earlier): article-cache.cc:398 assertion fail

[Duncan]

I'm finally feeling good enough to get some info on that bug I was talking
about.

Many, many posts, including some of my own made with 0.14.2.91, show up in
overviews/headers, but refuse to appear when I click on them to download. 
If I'm running pan 0.94 from a konsole, it'll print the following
assertion error:

(article-cache.cc:398 get_message): assertion "this->contains(*it)" failed.

I normally use gcc-4.1.0 with a number of CXXFLAGS, but compiling with
3.4.6 and with no optimizations whatsoever (only -march=k8 -pipe in
CXXFLAGS) yields the same results.  Likewise, I tried moving .pan2 and
rerunning pan 0.94, in case something was corrupted here.  No difference.

pan 0.14.2.91 downloads the same posts just fine.  I checked the .pan2
cache, and the message doesn't even get cached, tho it does appear to
download (net activity and the status bar says it's downloading, very
briefly).

Below my sig is a copy of one such message, as retrieved directly from
the pan 0.14.2.91 cache.  It's mine, so if necessary I can post the
message as saved in 0.14's pan.sent (the file system version, not just the
one pan displays) as well.

(BTW, Message attached as text using the pan-attach script I posted
sometime ago.  Crude solution, but it works...)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


Path: 
dukenews1.cox.net!duke.cox.net!cox.net!p01!dukeread03.POSTED!53ab2750!not-for-mail
From: Duncan <address@hidden>
Organization: Organization?  Me?
Subject: Re: Craig's List
User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table)
Message-Id: <address@hidden>
Newsgroups: cox.internet.community.phoenix
References: <address@hidden>
x-munging1: Usenet replies preferred,  If replying by mail,
x-munging2: do ALL the following to avoid the spam traps:
x-munging3: 1) Use plain text.  HTML format auto-trashed.
x-munging4: 2) Kill address reply2group and please phrases.
x-munging5: 3) Put " -news" at the END of the subject
x-munging6: (no quotes, space, dash, news, END)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Lines: 49
Date: Sun, 09 Apr 2006 06:36:44 -0700
NNTP-Posting-Host: 68.230.97.182
X-Complaints-To: address@hidden
X-Trace: dukeread03 1144589802 68.230.97.182 (Sun, 09 Apr 2006 09:36:42 EDT)
NNTP-Posting-Date: Sun, 09 Apr 2006 09:36:42 EDT
Xref: cox.net cox.internet.community.phoenix:8005
X-Received-Date: Sun, 09 Apr 2006 09:36:43 EDT (dukenews1.cox.net)

medadm posted <address@hidden>, excerpted below,  on Sun, 09
Apr 2006 00:08:59 -0700:

> Any idea why I cannot resolve craigslist.org of late? I've made no changes 
> to any of my configurations nor have I installed any new software or 
> hardware.
> 
> I have typed the url or clicked on it from my favorites but the outcome is 
> the same. I will ping it as well with 100% packet loss as a result.
> 
> Is anyone else experiencing this?
> 
> TIA for any suggestions you might offer.

It comes up fine here -- using my own DNS, not Cox's.

$host craigslist.org
craigslist.org has address 66.150.243.20

Try entering that IP address in your browser, and/or pinging it.  If it
works, you know it's a DNS problem.  If not, it's a route  problem.

The most likely DNS problem is often the result of a web accelerator gone
bad.  Many of them will stick the IPs for regularly visited sites in your
HOSTS file, where they do accelerate your visits by cutting out the remote
DNS lookup step -- UNTIL the IP address changes and no longer belongs to
that domain name.  Then you get sent off somewhere else.

Back on MSWormOS 9x, the CLI ping command didn't use the MSWormOS resolver
system so bypassed the HOSTS file and its possible incorrectness, but I'm
not sure if that's still the case with eXPrivacy or not.  In any case, if
you can get to the site by IP address, definitely check your windows dir
(or whatever dir eXPrivacy uses) and see if there's a HOSTS file (not
HOSTS.SAM, the .sam file is an inactive sample.  If so, temporarily rename
it and see if you can then get to the site via regular domain name.  The
HOSTS file itself is not something MSWormOS has by default, only something
it can use, so you should have no issues removing it, but always be
careful when following instructions from someone on the net (you don't
know me, maybe I'm having a joke on you -- I'm not, but how are you to
know that), and rename things to see if they are actually needed, before
deleting them. You can always rename them back if necessary, or delete
them after a month or two of testing, if indeed they aren't needed.

-- 
Duncan - Newsgroup replies preferred.  See x-munging headers.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html