Unhandled exception - trouble when connecting to the InterfacesAdded signal.

[mkcybi]

Hi @arfbtwn - I seem to be having an issue with using the properties branch.

We've been using your branch of dbus-sharp and seem to be getting an unhandled exception when we try to add an interface to one of our classes.

ProtSystem.Exception: Message length 993591296 exceeds maximum allowed 134217728 bytes
ocolInformation.MaxMessageLength + " bytes")

Please let me know if you need more information.
Stack trace

Revision
50cee72 (HEAD, origin/master, origin/HEAD, master) mapper: Correct GetInterfaceType(Type,string) [Nicholas Little]

DBus.Transports.Transport.ReadMessageReal () in /home/user/product/services/service/dbus-sharp/src/Protocol/Transport.cs:233
DBus.Transports.Transport.ReadMessage () in /home/user/product/services/service/dbus-sharp/src/Protocol/Transport.cs:155
DBus.Protocol.PendingCall.get_Reply () in /home/user/product/services/service/dbus-sharp/src/Protocol/PendingCall.cs:31
DBus.Connection.SendWithReplyAndBlock (msg={DBus.Protocol.Message}) in /home/user/product/services/service/dbus-sharp/src/Connection.cs:177
DBus.BusObject.SendMethodCall (iface="org.freedesktop.DBus", member="AddMatch", inSigStr="s", writer={DBus.Protocol.MessageWriter}, retType={System.Void}, exception=(null)) in /home/user/product/services/service/dbus-sharp/src/BusObject.cs:141
org.freedesktop.DBus.IBusProxy.AddMatch (rule="type='signal',path='/com/company/devices',interface='org.freedesktop.ObjectManager',member='Interfaces…") in
DBus.Bus.AddMatch (rule="type='signal',path='/com/company/devices',interface='org.freedesktop.ObjectManager',member='Interfaces…") in /home/user/product/services/service/dbus-sharp/src/Bus.cs:141
DBus.BusObject.ToggleSignal (iface="org.freedesktop.ObjectManager", member="InterfacesAdded", dlg={service.InterfacesAddedHandler}, adding=true) in /home/user/product/services/service/dbus-sharp/src/BusObject.cs:72
service.ObjectManagerProxy.add_InterfacesAdded (value={service.InterfacesAddedHandler}) in
service.FindDeviceName.Init () in /home/user/product/services/service/service/FindDeviceName.cs:43
service.MainClass.Main (Args={string[0]}) in /home/user/product/services/service/service/Main.cs:316

This is the definition of object manager

public delegate void InterfacesAddedHandler(ObjectPath object_path,
        IDictionary> interfaces_and_properties);

public delegate void InterfacesRemovedHandler(ObjectPath object_path, string[] interfaces);

[Interface("org.freedesktop.ObjectManager")]
public interface ObjectManager
{
    void GetManagedObjects(out IDictionary                 IDictionary>> objpath_interfaces_and_properties);
    event InterfacesAddedHandler InterfacesAdded;
    event InterfacesRemovedHandler InterfacesRemoved;
}

[arfbtwn]

Thanks for opening the issue :)

It is a complicated interface, I've worked with it before. After you mentioned the problem I knocked up a quick unit test with the interface which I've just committed to staging, in the test I call the method and connect to and fire both of the signals. The test passes at the moment but unfortunately it did at the time you reported the issue too so I wasn't able to identify what you're seeing.

Would you be able to pastebin an example program which generates the exception?

[chmorgan]

We will work on doing so. Might be a few days before we know when we'll be able to work on it. I'm surprised the issue isn't coming up in the other unit tests or from any other users.

What are your thoughts on getting this stuff back into mono proper? We'd prefer to work off of mainline if possible :-)

[arfbtwn]

@chmorgan: Indeed, it's very surprising! I have a fully green board in staging now :) I was hoping to see the problem when I wrote a the unit test for it...

On your question, it might depend on how well we do, but obviously I'm at the mercy of when the upstream maintainers choose to review the work. I dare say if we capture all the broken behaviours and apply a rigorous approach when solving them then there's a good chance of the changes being accepted.

[chmorgan]

Miguel and others asked to be prodded on the mailing list for pending PRs
that weren't being merged. If the unit tests are indeed green across the
board then it might justify merging it in. Or you could wait, we might
write a test case for it that reproduces in the next week or so. Overall
the changes are an improvement so....

On Wed, Mar 11, 2015 at 4:12 PM, Nicholas notifications@github.com wrote:

@chmorgan https://github.com/chmorgan: Indeed, it's very surprising! I
have a fully green board in staging now :) I was hoping to see the problem
when I wrote a the unit test for it...

On your question, it might depend on how well we do, but obviously I'm at
the mercy of when the upstream maintainers choose to review the work. I
dare say if we capture all the broken behaviours and apply a rigorous
approach when solving them then there's a good chance of the changes being
accepted.

—
Reply to this email directly or view it on GitHub
#1 (comment).