Re: [Pan-users] [latest git] Assertions hit in header-pane.cc

[Duncan]

walt posted on Sat, 27 Oct 2012 15:18:43 -0700 as excerpted:

> Hi Heinrich.  (I'm posting to user instead of devel to accommodate
> Duncan, who seems to be having some trouble with usenet technology ;)
> 
> I just hit the following asserts in header-pane.cc:
> 
> (pan:30080): Gtk-CRITICAL **: IA__gtk_tree_path_compare:
> assertion `a != NULL' failed
> (pan:30080): Gtk-CRITICAL **: IA__gtk_tree_path_compare:
> assertion `b != NULL' failed
> 
> AFAICS, the only place that would happen is in 'on_tree_change', which
> then apparently hits the assertion in 'get_article' twice in a row (I
> think) while doing the compare.
> 
> I believe that assertion has been there for a long time (?) so why am I
> hitting it now for the first time?  I set my servers to not expire
> articles ever, so maybe there are some non-existent articles listed in
> my header pane, and they may be causing trouble months after I changed
> the expiration setting?  Dunno, just a thought.
> 
> FWIW, I think I did click on a header just before the assertion
> happened, but the header was definitely a new header, not an old one.

That message looks familiar, but I'm not sure from where.  I /might/ have 
seen it in a bug report I checked when doing a git whatchanged a few 
weeks ago.  (There haven't been many commits recently.)

Are you sure you're on current git?  Because if I'm correct in the above, 
that was supposed to be fixed (perhaps not successfully, however). You 
can normally check my headers to see what I'm on (GIT f91bd24 currently 
and I just did a pull, no updates).  I tried that with yours, but you're 
posting with a mozilla thunderbird user agent, so you'd appear not to be 
using gmane and pan for this list.

But wherever it was I read about it, yes, that assertion had been there 
for awhile.  AFAIK the discussion was that new gtk's doing something 
differently now, and I think the solution was to simply remove that 
assertion as no longer valid.

But that's entirely from possibly faulty memory... and/or the assertion 
might have been similar, but not the same one.  (Maybe one instance of it 
was removed and you're hitting a different one now.)

I'll do a git whatchanged and see if I can find it again...

> Oh, one other unrelated bug I see:  the 'dl-meter-show' setting seems to
> be ignored when pan first starts, but if I set it to 'false' in the
> settings dialog, the dl-meter disappears until the next time I start
> pan.

Your description doesn't seem to match the UI I see for the dl meter 
here.  Are you possibly running pan built against gtk3?

I'm running pan built against gtk2, FWIW, and the only dl meter I see is 
a small segment of the status bar just to the right of the connections 
segment, but to the left of the tasks segment.

The only way I see to configure it is to click that status bar segment, 
which produces a small dialog, titled "Pan Download Meter Preferences".  
In it, there's a couple checkboxes (warn and disconnect from server), a 
textbox/spinner combo with the limit number, a dropdown MB/GB list, a 
reset button and the OK button.

I don't see any way to turn off the dl-meter status bar segment, and if 
there was, I wouldn't know how to turn it back on again, since the status 
bar segment I'd click to get the dl-meter prefs would be gone.

And, AFAIK, there's nothing labeled "settings" for it at all.  It's all 
"Preferences".

I looked in the main pan preferences dialog as well.  Nothing I could 
find there for it either, tho it's possible I just missed it.  I also 
looked in the edit menu, since that's where many of the prefs dialogs are 
listed.  Nothing there either.

So somehow, we seem to be running two different pans, despite us both 
having "latest git".  Maybe part of it /is/ the gtk version built 
against, but I would have /thought/ the general UI should be the same.

FWIW for the future, stating the git commit (it's in pan's about box as 
well as in the headers, if you prefer looking there to checking git) 
instead of simply "latest git" should eliminate any confusion in that 
regard.  If people are beyond that, a git show <commit> should bring it 
up and a git whatchanged <commit>.. will output changes since then.  If 
they're before that, it won't show, and they'll know to try a pull.  If 
it doesn't come in with a pull, maybe they're running a different repo, 
or the remote is down.  Regardless, having a commit-id nails it down WAY 
better than "latest git" does.

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