Strange SIGPIPE when emitting signal with STRV

[Rob Taylor]

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...

Thanks,
Rob Taylor