Hi, On Fri, 2010-05-14 at 10:57 +0200, Iago Toral Quiroga wrote: > Hi Joaquim, > > thanks for the bug report. > > Checking out your patch I am a bit surprised, because that patch should > not be needed: browse_result_relay_cb should never be invoked with a > NULL source object. The source object is referenced (g_object_ref) when > a browse/search operation is started and unreferenced (g_object_unref) > when the operation is done (remaining==0 has been emitted by the > plugin). A plugin must not emit a new result after remaining=0 has been > sent, for that signals the end of the operation. > > I can only think of these reasons for this to happen: > > 1) A plugin is emitting results after sending remaining == 0. > 2) Someone is unreffing the source object somewhere twice. > 3) There is some other kind of memory management problem somewhere > > The g_return_if_fail in your patch might prevent the segfault, but it is > masquerading the real problem. > > I would appreciate if you can provide backtrace information extracted > from gdb and any info you can get on the "remaining" parameter being > passed on to the browse_result_cb when this problem happens. Probably it > is better if you attach this information and your patch to bugzilla. Well, I installed the upstream version again and tested it and it no longer fails... o_0 Could it be that some part of the Jamendo service was failing then and it ended up with some NULL source to be passed? > > Also, since this is only happening when using rygel-grilo I wonder if > the source of the problem might live there. Another issue might be > related to you using Python, since AFAIK, the introspection support for > Grilo is not stable yet. I'm using Python but not the bindings, I'm using Rygel-Grilo. So, now that I cannot test it anymore, what should we do? -- Joaquim Rocha
Attachment:
signature.asc
Description: This is a digitally signed message part