Strange SIGPIPE when emitting signal with STRV
robtaylor at floopily.org
Wed Oct 26 10:45:03 PDT 2005
Havoc Pennington wrote:
> On Wed, 2005-10-26 at 13:22 +0100, Rob Taylor wrote:
>>Any ideas what i'm doing wrong and what's causing the pipe to break?
> You probably want the verbose log from the server side, my guess is the
> server felt the message was not well-formed.
> This is a common cause of confusion/debugging, if you figure out the
> specific case I think we should try to cover it with one of:
> - if the message is well-formed but just not valid (e.g. a missing
> required header field) we should probably return an error reply
> instead of disconnecting
> - if the message is "corrupt" / not well-formed we should try to
> print a warning from the client side library (dbus_return_if_fail)
> - we should print client side warnings in the first case too (if e.g.
> you try to send a signal without a signal name, or whatever)
> If we wanted to be systematic about this, someone could go through the
> message validation code and find all the things it will reject a message
> on the basis of, and see if the client side also complains about them.
> The one limitation is that it could be a noticeable performance hit if
> we're doing all kinds of validation on the client side just to print out
> warnings. So there are probably a few things you can do wrong that we'd
> end up not wanting to warn about. Cheap checks like "is this field
> present?" should be ok though.
Thanks for the pointer, in this case it was definitly user error..
passing &msg, rather than msg to g_emit_signal.
Definitely not an easy case to catch. ;)
I guess to help in such situations it could be useful to have a debug
mode that causes the client to call _dbus_validate_body_with_reason on
every sent message, allowing for easier debugging in this case.
I might save that one for a rainy day...
More information about the dbus