After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 96258 - Cannot load new headers
Cannot load new headers
Status: RESOLVED FIXED
Product: Pan
Classification: Other
Component: general
0.13.1
Other FreeBSD
: Normal major
: 0.13.2
Assigned To: Charles Kerr
Pan QA Team
Depends on:
Blocks:
 
 
Reported: 2002-10-19 19:31 UTC by kensama
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
log my pan session (1.84 KB, text/plain)
2002-10-20 16:39 UTC, Billy
  Details
jandrese's shorter runlog. (148.94 KB, text/plain)
2002-10-20 19:24 UTC, Christophe Lambin
  Details
If either of you is compiling from source, could you try this small patch ? (870 bytes, patch)
2002-10-20 22:19 UTC, Christophe Lambin
none Details | Review

Description kensama 2002-10-19 19:31:52 UTC
After I start pan and load a group, if I drop back to the groups list and
double click on a new group, it does not load the headers (the headers view
still shows the old group).  If I manually load the headers by right
clicking on the group and choosing "new headers", the headers view still
shows the old group instead.  The only way to load a new group is to shut
down pan and restart it.  

This happens weather the group is on the same server or on a different
server.
Comment 1 Christophe Lambin 2002-10-20 11:07:37 UTC
Could you attach a runlog to this bugreport ?
http://pan.rebelbase.com/bugs/#runlog
Comment 2 jandrese 2002-10-20 14:40:08 UTC
I have attached a runlog of the following session:

1. Start Pan
2. Open "alt.binaries.pictures.anime"
3. Open "alt.binaries.test"  This caused a "load new groups" window to
appear, I clicked "load new headers".  The Headers window did not
update when the headers finished downloading.
4. Switched to a different server, attempted to load
"alt.binaries.anime.tenchi"  Nothing happened (no headers loaded, and
the headers window was not updated).  The headers window still shows
the headers from "alt.binaries.pictures.anime"
Comment 3 jandrese 2002-10-20 14:49:54 UTC
I am creating a link to the runlog, as I cannot seem to get it to
attach to the bug report.

http://www.ceyah.org/~jandrese/pan.runlog
Comment 4 Billy 2002-10-20 16:39:33 UTC
Created attachment 11710 [details]
log my pan session
Comment 5 Billy 2002-10-20 16:42:14 UTC
Oops well here is my comment for the above log file.  I think the
problem might have something to do the tasks?  When I drop the tasks
and retries down to 1, and I load a newsgroup, it doesn't want to do
anything else after a group is loaded.  Whenever I click on another
group to view it doesn't even get the headers, it's like the task that
originally got the group the first time hangs and wont let up.  The
log is with the task and retries set back to 4.  Sorry if this is posted
twice, this is kindaof confusing :)
Comment 6 jandrese 2002-10-20 16:53:24 UTC
Good thought, but my connections are set at 4 with no reserve.

By the way, what happened to clicking on the "N connections" box (next
to the N tasks box on the bottom) and having it pop up the connection
settings?  

I've generated a shorter runlog:
http://www.ceyah.org/~jandrese/pan-short.runlog
In this case: 
1. Start pan
2. Load "rec.games.mecha"
3. Load "rec.games.roguelike.angband"
(rec.games.mecha's headers stay in the header pane).
4. quit.
Comment 7 Christophe Lambin 2002-10-20 19:22:52 UTC
Billy: that's not a runlog; that's the contents of your log. :)  See
http://pan.rebelbase.com/bugs/#runlog on how to generate one.

jandrese: thanks for the runlog. I'll attach it to this report. 
Comment 8 Christophe Lambin 2002-10-20 19:24:07 UTC
Created attachment 11713 [details]
jandrese's shorter runlog.
Comment 9 Christophe Lambin 2002-10-20 19:58:47 UTC
jandrese, billy: what version of glib2 are you using?
Comment 10 Christophe Lambin 2002-10-20 20:06:44 UTC
Note to developers:

The following subset of the runlog shows what's going on:

(articlelist.c:3490:set_group_mainthread_begin():set_group_mainthread_begin)(thread
0x819a1e0)(time 16:49:53)(depth   1) TRACE: + set_group_mainthread_begin
(articlelist.c:3504:set_group_mainthread_begin():set_group_mainthread_begin)(thread
0x819a1e0)(time 16:49:53)(depth   0) TRACE: - set_group_mainthread_begin
(articlelist.c:3431:set_group_worker():    set_group_worker)(thread
0x82b3c40)(time 16:49:53)(depth   1) TRACE: + set_group_worker
(articlelist.c:3479:set_group_worker():    set_group_worker)(thread
0x82b3c40)(time 16:49:53)(depth   0) TRACE: - set_group_worker
(articlelist.c:3371:set_group_mainthread_end():set_group_mainthread_end)(thread
0x819a1e0)(time 16:49:53)(depth   1) TRACE: + set_group_mainthread_end
(articlelist.c:3418:set_group_mainthread_end():set_group_mainthread_end)(thread
0x819a1e0)(time 16:49:54)(depth   0) TRACE: - set_group_mainthread_end
(articlelist.c:3490:set_group_mainthread_begin():set_group_mainthread_begin)(thread
0x819a1e0)(time 16:49:57)(depth   1) TRACE: + set_group_mainthread_begin
(articlelist.c:3504:set_group_mainthread_begin():set_group_mainthread_begin)(thread
0x819a1e0)(time 16:49:57)(depth   0) TRACE: - set_group_mainthread_begin
(articlelist.c:3431:set_group_worker():    set_group_worker)(thread
0x82b98a0)(time 16:49:57)(depth   1) TRACE: + set_group_worker


It's hanging on set_group_worker(), so most likely it's blocked on
g_static_mutex_lock (&switch_mutex).  This mutex gets unlocked at the
end of set_group_mainthread_end() (unconditionally, so weird that it
would still be locked at the next call of set_group_worker).

(switch_mutex prevents two switches occuring at the same time. we
could remove it, but we'd need to review at least article-toolbar.c
for threading issues.)
Comment 11 jandrese 2002-10-20 20:28:05 UTC
I'm running FreeBSD 4.7, I'm not using glibc.
Comment 12 Christophe Lambin 2002-10-20 21:00:19 UTC
jandrese: glib2, not glibc.
Comment 13 Christophe Lambin 2002-10-20 22:19:11 UTC
Created attachment 11718 [details] [review]
If either of you is compiling from source, could you try this small patch ?
Comment 14 jandrese 2002-10-20 22:31:24 UTC
glib-2.0.6
Comment 15 jandrese 2002-10-20 22:36:18 UTC
The patch seems to have solved the problem.
Comment 16 Billy 2002-10-21 03:31:54 UTC
Sorry for posting the wrong log :)  i'm running 2.0.6 of glib also. 
How exactly do you go about aplying the patch, i'm kind of a newbie :)
Comment 17 kensama 2002-10-21 13:11:29 UTC
Pan seems to be stable (no crashes with heavy use after ~12 hours)
with this new patch.  Thanks for promptly fixing the problem
Christophe.  This is why the Pan team rules.  
Comment 18 Christophe Lambin 2002-10-21 18:27:25 UTC
jandrese, kensama: thanks for the update.

billy: to apply this patch, save it to /tmp/panpatch, go to the
directory where the Pan sources are installed and type:

   $ cd pan
   $ patch < /tmp/panpatch.txt

and rebuild.
Comment 19 Billy 2002-10-22 01:25:38 UTC
Alright! I've applied the patch!  It fixed the problem, it's all
magically now :)