GNOME Bugzilla – Bug 96258
Cannot load new headers
Last modified: 2004-12-22 21:47:04 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.
Could you attach a runlog to this bugreport ? http://pan.rebelbase.com/bugs/#runlog
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"
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
Created attachment 11710 [details] log my pan session
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 :)
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.
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.
Created attachment 11713 [details] jandrese's shorter runlog.
jandrese, billy: what version of glib2 are you using?
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.)
I'm running FreeBSD 4.7, I'm not using glibc.
jandrese: glib2, not glibc.
Created attachment 11718 [details] [review] If either of you is compiling from source, could you try this small patch ?
glib-2.0.6
The patch seems to have solved the problem.
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 :)
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.
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.
Alright! I've applied the patch! It fixed the problem, it's all magically now :)