Jim Mathies [:jimm] Reporter
	Description • 9 years ago

We track KillHard aborts which are aborts of the content process (all your tabs crash) when an api handler on the chrome side fails. An abort is triggered when the ipc Recv handler returns false indicating an unexpected unrecoverable error.

Generally we try to avoid these types of aborts except for very serious and unexpected errors since the result is crashed tabs. A more stable way of handling this type of error involved return true for the Recv call and return an error code to the content process through a parameter passed to the handler.

On nightly we're seeing a lot of aborts related to three a11y related api handler failures:

'(msgtype=0x4A0005,name=PDocAccessible::Msg_StateChangeEvent) Processing error: message was deserialized, but the handler returned false (indicating failure)'
'(msgtype=0x4A0003,name=PDocAccessible::Msg_ShowEvent) Processing error: message was deserialized, but the handler returned false (indicating failure)'
'(msgtype=0x4A0007,name=PDocAccessible::Msg_TextChangeEvent) Processing error: message was deserialized, but the handler returned false (indicating failure)'

It would be great if the a11y team could do an audit of these and other common apis looking for cases where we can avoid returning false for these handlers and instead return an error code to content. This way the user can continue using the browser despite something maybe not working quite right in their a11y client if they have an a11y client at all.

	Trevor Saunders (:tbsaunde)
	Comment 1 • 9 years ago

> '(msgtype=0x4A0005,name=PDocAccessible::Msg_StateChangeEvent) Processing
> error: message was deserialized, but the handler returned false (indicating
> failure)'

so the only way for that to fail is because we don't know about an id the child gave us.  That's a bug possibly caused by the badness in the ShowEvent msg.

> '(msgtype=0x4A0003,name=PDocAccessible::Msg_ShowEvent) Processing error:
> message was deserialized, but the handler returned false (indicating
> failure)'

I suspect at least to some dagree this is just the result of Bill's patch in bug 1100602.

> '(msgtype=0x4A0007,name=PDocAccessible::Msg_TextChangeEvent) Processing
> error: message was deserialized, but the handler returned false (indicating
> failure)'

same as StateChangeEvent.

> It would be great if the a11y team could do an audit of these and other
> common apis looking for cases where we can avoid returning false for these
> handlers and instead return an error code to content. This way the user can
> continue using the browser despite something maybe not working quite right
> in their a11y client if they have an a11y client at all.

I don't think any of these "are normal conditions that should be handled".  However we can paper over these if we have to, but we do need to find the source of the bugs some time.

	Jim Mathies [:jimm] Reporter
	Comment 2 • 9 years ago

(In reply to Trevor Saunders (:tbsaunde) from comment #1)
> > '(msgtype=0x4A0005,name=PDocAccessible::Msg_StateChangeEvent) Processing
> > error: message was deserialized, but the handler returned false (indicating
> > failure)'
> 
> so the only way for that to fail is because we don't know about an id the
> child gave us.  That's a bug possibly caused by the badness in the ShowEvent
> msg.
> 
> > '(msgtype=0x4A0003,name=PDocAccessible::Msg_ShowEvent) Processing error:
> > message was deserialized, but the handler returned false (indicating
> > failure)'
> 
> I suspect at least to some dagree this is just the result of Bill's patch in
> bug 1100602.
> 
> > '(msgtype=0x4A0007,name=PDocAccessible::Msg_TextChangeEvent) Processing
> > error: message was deserialized, but the handler returned false (indicating
> > failure)'
> 
> same as StateChangeEvent.

These started showing up fairly recently and are nightly only so maybe this is a regression.

Bill, any ideas? Note the KillHard error lists at the bottom here -

http://www.mathies.com/mozilla/client-abort-report-nightly.txt

	Trevor Saunders (:tbsaunde)
	Comment 3 • 9 years ago

(In reply to Jim Mathies [:jimm] from comment #2)
> (In reply to Trevor Saunders (:tbsaunde) from comment #1)
> > > '(msgtype=0x4A0005,name=PDocAccessible::Msg_StateChangeEvent) Processing
> > > error: message was deserialized, but the handler returned false (indicating
> > > failure)'
> > 
> > so the only way for that to fail is because we don't know about an id the
> > child gave us.  That's a bug possibly caused by the badness in the ShowEvent
> > msg.
> > 
> > > '(msgtype=0x4A0003,name=PDocAccessible::Msg_ShowEvent) Processing error:
> > > message was deserialized, but the handler returned false (indicating
> > > failure)'
> > 
> > I suspect at least to some dagree this is just the result of Bill's patch in
> > bug 1100602.
> > 
> > > '(msgtype=0x4A0007,name=PDocAccessible::Msg_TextChangeEvent) Processing
> > > error: message was deserialized, but the handler returned false (indicating
> > > failure)'
> > 
> > same as StateChangeEvent.
> 
> These started showing up fairly recently and are nightly only so maybe this
> is a regression.

I doubt it is in any meaningful sense.  That particular message is very new.  For the others I'd say a child crash is better than a  possible memory curruption in the parent.

	Bill McCloskey [inactive unless it's an emergency] (:billm)
	Comment 4 • 9 years ago

I'm going to dupe this against bug 1185726 since it has a regression range.

	Trevor Saunders (:tbsaunde)
	Comment 5 • 9 years ago

(In reply to Bill McCloskey (:billm) from comment #4)
> I'm going to dupe this against bug 1185726 since it has a regression range.

you beat me