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 _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
