922215 - Add privileged Web API to intentionally crash in various ways

Status: NEW

(Core :: DOM: Device Interfaces, defect, P3)

Description

[Benjamin Smedberg]

Just as we now have a privileged API for accessing the crash storage area, we would also like a privileged API which allows us to intentionally crash various processes, for the purposes of testing crash reporting and making sure that symbols are working.

APIs need to be:
* crash this app process in various ways, similar to the current nsTestCrasher:
** access violation
** pure-virtual
** runtimeabort
** MOZ_CRASH
** abort()
* crash the B2G process (in the same ways if possible, but a single way is probably sufficient)

Fabrice, I'm going to mark this as helpwanted, are you interested in mentoring or do you know of somebody else who'd be a good mentor?

Comment 1

[[:fabrice] Fabrice Desré]

Benjamin, I will be happy to mentor here.

Comment 2

[(no longer active)]

When you say "web" API, do you want this exposed to content?

Comment 3

[Benjamin Smedberg]

I want this exposed to an app that we can load onto an unrooted phone in order to properly QA crash reporting on release builds.

Comment 4

[(no longer active)]

(In reply to comment #3)
> I want this exposed to an app that we can load onto an unrooted phone in order
> to properly QA crash reporting on release builds.

What kind of privilege level were you thinking of?  This is obviously extremely dangerous... :(

Comment 5

[Benjamin Smedberg]

Well, I figured we'd have a privilege for this just as we have a privilege for accessing the crash storage area. I'm not sure what's so dangerous about this: you can force the phone to reboot, but there's no real security risk involved.

Comment 6

[[:fabrice] Fabrice Desré]

That could be certified only and rely on sideloading the test app with the remote debugging protocol.

Comment 7

[Robert Kaiser]

If that's something that QA can do on production devices, then yes, that's fine, good and what we'd expect.

Comment 8

[(no longer active)]

(In reply to comment #6)
> That could be certified only and rely on sideloading the test app with the
> remote debugging protocol.

That sounds good!