NPAPI:ErrorReporting: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Created page with "= Status = Under Consideration = Problem Summary = Currently there are no mechanisms available for browser plug-ins to add plug-in specific data into the crash dumps reported ...")
 
Line 32: Line 32:
Parameters:
Parameters:
* key – unique string identifying the memory block
* 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
* flags - NPMEM_CHARACTER_DATA - the data is character data which can be <br>presented as UTF8/ASCII data NPMEM_NOT_PERSONAL - the data is guaranteed to not contain any <br> personally identifying information such as URLs, cookie data, etc
* pMemBlock  - The starting address of the memory block
* pMemBlock  - The starting address of the memory block
* sizeOfMemBlock – The size of the memory block in bytes
* sizeOfMemBlock – The size of the memory block in bytes

Revision as of 11:31, 31 March 2011

Status

Under Consideration

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.


Existing Discussions and Documentation

Related Documentation

API Requirements

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 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 <br>presented as 	UTF8/ASCII data NPMEM_NOT_PERSONAL - the data is guaranteed to not contain any <br>	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.