Bug 187452 - dbus-sharp
dbus-sharp
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: dbus-sharp (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Alexander Larsson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-30 18:55 EST by Eric Moret
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-30 09:24:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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


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

  None (edit)
Description Eric Moret 2006-03-30 18:55:00 EST
Created attachment 127087 [details]
Patch to fix the issue
Comment 1 Eric Moret 2006-03-30 18:55:00 EST
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 15:16:26 EDT
moving this to devel and dbus-sharp and reassigning to Alex.
Comment 4 Alexander Larsson 2006-08-23 08:55:10 EDT
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 11:49:56 EDT
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 04:27:52 EDT
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 17:18:29 EDT
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 03:25:24 EDT
That seems much better. Could you attach the patch for that?
Comment 9 Christian Krause 2006-08-29 15:54:10 EDT
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-29 22:48:04 EDT
That fixes it for me, as well. Thanks, Christian.
Comment 11 Alexander Larsson 2006-08-30 09:24:20 EDT
Fixed in 0.63-6

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