NPAPI:ErrorReporting: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
Line 3: Line 3:
Under Consideration
Under Consideration


= Problem Summary =
= Contributors =


Currently there are no mechanisms available for browser plug-ins to add plug-in specific data into the crash dumps reported by browsers. Additional information added by browser plug-ins will facilitate easier and faster trouble shooting of plug-ins. This necessitates browsers to provide interfaces through which plug-in can indicate to the browser, plug-in specific data that it needs browser to capture as part of crash dumps in case a crash occurs.The NPAPI doesn’t have any interfaces to send plug-in’s custom data along with crash dump when an Unhandled exception occurs in the plug-in. To support this we are proposing an extension to the current API.
* Last modified: March 31st, 2011
* Authors: Sandeep Akula(Adobe Systems), Vinod Menon(Adobe Systems)


= Problem Summary =


= Existing Discussions and Documentation =
Currently there are no mechanisms available for browser plug-ins to add plug-in specific data into the crash dumps reported by browsers. Additional information added by browser plug-ins will facilitate easier and faster trouble shooting of plug-ins. This necessitates browsers to provide interfaces through which plug-in can indicate to the browser, plug-in specific data that it needs browser to capture as part of crash dumps in case a crash occurs.The NPAPI doesn’t have any interfaces to send plug-in’s custom data along with crash dump when an unhandled exception occurs in the plug-in. To support this we are proposing an extension to the current API.


== Related Documentation ==
= API Requirements =


= API Requirements =
?


= Current Proposal =
= Current Proposal =
* Last modified: March 31st, 2011
* Authors: Sandeep Akula(Adobe Systems)/Vinod Menon(Adobe Systems)
* Contributors:


The current proposal is to add two new  methods for registering and unregistering memory  
The current proposal is to add two new  methods for registering and unregistering memory  
Line 43: Line 41:
* NPERR_INVALID_PARAM - If the registration fails
* NPERR_INVALID_PARAM - If the registration fails
* NPERR_NO_ERROR - If successful
* NPERR_NO_ERROR - If successful
</pre>
</pre>


Line 61: Line 58:
* NPERR_INVALID_PARAM  - If un registration fails
* NPERR_INVALID_PARAM  - If un registration fails
* NPERR_NO_ERROR - If un resgitation succeeds
* NPERR_NO_ERROR - If un resgitation succeeds
</pre>
</pre>


== Open Issues ==
== Open Issues ==
* We need to check with browser vendor crash reporting teams to make sure we can handle arbitrary blocks of memory. Right now, for example, I think Mozilla is only set up to handle string annotations and I'm not sure what additional challenges random memory will pose.
* We need to check with browser vendor crash reporting teams to make sure we can handle arbitrary blocks of memory. Right now, for example, I think Mozilla is only set up to handle string annotations and I'm not sure what additional challenges random memory will pose.

Revision as of 15:41, 14 April 2011

Status

Under Consideration

Contributors

  • Last modified: March 31st, 2011
  • Authors: Sandeep Akula(Adobe Systems), Vinod Menon(Adobe Systems)

Problem Summary

Currently there are no mechanisms available for browser plug-ins to add plug-in specific data into the crash dumps reported by browsers. Additional information added by browser plug-ins will facilitate easier and faster trouble shooting of plug-ins. This necessitates browsers to provide interfaces through which plug-in can indicate to the browser, plug-in specific data that it needs browser to capture as part of crash dumps in case a crash occurs.The NPAPI doesn’t have any interfaces to send plug-in’s custom data along with crash dump when an unhandled exception occurs in the plug-in. To support this we are proposing an extension to the current API.

API Requirements

?

Current Proposal

The current proposal is to add two new methods for registering and unregistering memory blocks

NPError NPN_ErrorReportingRegisterMemoryBlock(
const char* key, 
unit flags,
void* pMemBlock, 
size_t sizeOfMemBlock);

Parameters:
* key – unique string identifying the memory block
* flags - NPMEM_CHARACTER_DATA - the data is character data which can be 
presented as 	UTF8/ASCII data 
NPMEM_NOT_PERSONAL - the data is guaranteed to not contain any 
personally identifying information such as URLs, cookie data, etc
* pMemBlock   - The starting address of the memory block
* sizeOfMemBlock – The size of the memory block in bytes

Return Value:
* NPERR_OUT_OF_MEMORY_ERROR - If the memory size exceeds the maximum size allowed
* NPERR_INVALID_PARAM - If the registration fails
* NPERR_NO_ERROR - If successful
  • If the API is called with same key that was registered earlier, then API call with

succeed and call will override the old pointer and length values.

  • Plugin is allowed to register as many memory blocks as it wants
  • NPN_GetValue with key "NPNVmaxCrashMemoryBlockSize" can be used to get the maximum

block size that could be registered

NPError NPN_ErrorReportingUnregisterMemoryBlock(const char* key); 

Parameters:
* key - key value which was used to register the memory block

Return Value:
* NPERR_INVALID_PARAM  - If un registration fails
* NPERR_NO_ERROR - If un resgitation succeeds

Open Issues

  • We need to check with browser vendor crash reporting teams to make sure we can handle arbitrary blocks of memory. Right now, for example, I think Mozilla is only set up to handle string annotations and I'm not sure what additional challenges random memory will pose.