On Thu, 2009-05-21 at 17:07 +0100, Bastien Nocera wrote:
> On Thu, 2009-05-21 at 01:49 -0400, Jon Masters wrote:
> <snip>
> > I like podcasts. A lot. I also like rhythmbox (mostly). I've been
> > wondering recently why I would occasionally not be able to download
> > podcasts in rhythmbox. It seemed to be related to when I was connected
> > to a particular VPN and so I had dismissed it as being network DNSness
> > weirdness. But then it started happening much more often. Tonight, I
> > decided it was probably more than occasional network weirdness.
> >
> > So I decided "I'll just fire up gdb on rhythmbox". Many debuginfo
> > packages, cscopes, hacked up source, etc. later on, I discover the
> > "problem" is in abstraction layer number 2 - totem-pl-parser. So I
> > download the source to this package also, rebuild and hack it up. I
> > eventually discovered that various GError objects were happily telling
> > me that the maximum number of open files had been exceeded, but totem
> > never exposes this to rhythmbox, and the latter just has no idea what
> > the heck is causing it to fail. Some serious fail happening there.
>
> Can I have my bugzilla?
Filing upstream totem bug and RH BZ at the moment.
> (and some proof that totem-pl-parser is leaking descriptors...).
There's some code in there looking for a PROP_DEBUG set on the parser -
am I supposed to set that by passing some option to rhythmbox? rhymbox
-d didn't seem sufficient. Isn't there some ENV var I can set to get it
to spew out a lot more useful info?
I think all you need to do is create a long playlist of podcasts and
watch what's happening in totem-pl-parser. Aside from the possible
leaking of descriptors, if you look at around line 660, you'll see:
stream = g_file_read (file, NULL, &error);
if (stream == NULL) {
<couple of error cases caught but not max open files>
}
The GError 'error' object knows what failed though.
Jon.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
