Bug 187452 - dbus-sharp
Summary: dbus-sharp
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: dbus-sharp
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Alexander Larsson
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-03-30 23:55 UTC by Eric Moret
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2006-08-30 13:24:20 UTC


Attachments (Terms of Use)
Patch to fix the issue (1.03 KB, patch)
2006-03-30 23:55 UTC, Eric Moret
no flags Details | Diff
revised patch (1.17 KB, patch)
2006-08-29 19:54 UTC, Christian Krause
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 5716 None None None Never
GNOME Bugzilla 327595 None None None Never

Description Eric Moret 2006-03-30 23:55:00 UTC
Created attachment 127087 [details]
Patch to fix the issue

Comment 1 Eric Moret 2006-03-30 23:55:00 UTC
Description of problem:
Banshee reports Could not connect to D-Bus

Version-Release number of selected component (if applicable):
dbus-0.61-3

How reproducible:
Always

Steps to Reproduce:
1. start banshee from command line
2. go to View ! Logs Event Viewer menu
3. see the D-Bus warning message
  
Actual results:
D-Bus not working in banshee

Expected results:
Should not report an error

Additional info:

Comment 2 John (J5) Palmieri 2006-08-22 19:16:26 UTC
moving this to devel and dbus-sharp and reassigning to Alex.

Comment 4 Alexander Larsson 2006-08-23 12:55:10 UTC
I don't understand this patch. Why would the return value from
dbus_connection_get_data on the dbus-sharp slot ever return anything that wasn't
a connection. Furthermore, how can "((GCHandle)rawThis).Target ==
typeof(DBus.Connection)" ever be true? Target is a DBus.Connection object, not a
type.

Comment 5 Christian Krause 2006-08-27 15:49:56 UTC
Hi Alexander,

(In reply to comment #4)
> I don't understand this patch. Why would the return value from
> dbus_connection_get_data on the dbus-sharp slot ever return anything that wasn't
> a connection. Furthermore, how can "((GCHandle)rawThis).Target ==
> typeof(DBus.Connection)" ever be true? Target is a DBus.Connection object, not a
> type.

Please see https://bugs.freedesktop.org/show_bug.cgi?id=5716 for my analysis of
this problem. In short:

The Connection's Target is alloacted as a weak reference. So it is possible,
that dbus_connection_get_data returns returns a valid "pointer", but accessing
it's target fails, because it is already destroyed by the garbage collection. 
Please see the mentioned bug report for 2 possible solutions:
1. allocate not a weak, but a "GCHandleType.Normal" reference
or
2. use a patch like the one from Eric, which explicitly checks whether the
Target is still valid

Please have a look at the linked bug report on freedesktop.org.



Comment 6 Alexander Larsson 2006-08-28 08:27:52 UTC
Ok, that explains the need for the change. 

I still don't understand this part though:
 "((GCHandle)rawThis).Target == typeof(DBus.Connection)"

The left hand side is a reference to an object of type "DBus.Connection", but
the right hand side is a reference to an object of type "Type". How can it ever
be true?

Comment 7 Christian Krause 2006-08-28 21:18:29 UTC
Hi Alex,

(In reply to comment #6)
> Ok, that explains the need for the change. 
> 
> I still don't understand this part though:
>  "((GCHandle)rawThis).Target == typeof(DBus.Connection)"
> 
> The left hand side is a reference to an object of type "DBus.Connection", but
> the right hand side is a reference to an object of type "Type". How can it ever
> be true?

I've looked into the code again, and sure, you are right. This doesn't make much
sense. ;-) It worked only, because the check was always false and so every time
a new Connection was created.

Nevertheless it seems, that checking the GCHandle rawThis isn't sufficient.
Additionally it must be checked, whether the target is still not removed by the
garbage collector.

I've tried the following check which makes more sense
"if (rawThis != IntPtr.Zero &&  (((GCHandle)rawThis).Target != null) ) {"
and it works as well. 

Alex, what do you think? 


Comment 8 Alexander Larsson 2006-08-29 07:25:24 UTC
That seems much better. Could you attach the patch for that?


Comment 9 Christian Krause 2006-08-29 19:54:10 UTC
Created attachment 135166 [details]
revised patch

I've attached a new patch which addresses the discussed issue. This new patch
works fine for me.

Comment 10 Peter Gordon 2006-08-30 02:48:04 UTC
That fixes it for me, as well. Thanks, Christian.

Comment 11 Alexander Larsson 2006-08-30 13:24:20 UTC
Fixed in 0.63-6


Note You need to log in before you can comment on or make changes to this bug.