NPAPI:ErrorReporting: Difference between revisions
No edit summary |
|||
| (9 intermediate revisions by 2 users not shown) | |||
| Line 5: | Line 5: | ||
= Contributors = | = Contributors = | ||
* Last modified: | * Last modified: June 6, 2011 | ||
* Authors: Sandeep Akula (Adobe Systems), Vinod Menon (Adobe Systems) | * Authors: Sandeep Akula (Adobe Systems), Vinod Menon (Adobe Systems) | ||
* Contributors: Josh Aas (Mozilla Corporation) | * Contributors: Josh Aas (Mozilla Corporation) | ||
| Line 19: | Line 19: | ||
<pre> | <pre> | ||
NPError NPN_ErrorReportingRegisterMemoryBlock(const char* key, | NPError NPN_ErrorReportingRegisterMemoryBlock(const char* key, | ||
uint32_t flags, | |||
void* pMemBlock, | void* pMemBlock, | ||
size_t sizeOfMemBlock); | size_t sizeOfMemBlock); | ||
| Line 28: | Line 28: | ||
* <code>key</code>: unique string identifying the memory block | * <code>key</code>: unique string identifying the memory block | ||
* <code>flags</code>: | * <code>flags</code>: | ||
** | ** Future use, no flags defined now. | ||
* <code>pMemBlock</code>: The starting address of the memory block. | |||
* <code>pMemBlock</code>: The starting address of the memory block | |||
* <code>sizeOfMemBlock</code>: The size of the memory block in bytes | * <code>sizeOfMemBlock</code>: The size of the memory block in bytes | ||
| Line 39: | Line 38: | ||
* <code>NPERR_NO_ERROR</code>: If successful | * <code>NPERR_NO_ERROR</code>: If successful | ||
Registered buffers must contain textual UTF8/ASCII data which is <code>NULL</code> terminated. Non-textual data can be encoded as text before it is placed in a registered buffer. | |||
Calling <code>NPN_GetValue</code> with new key <code>NPNVmaxCrashMemoryBlockSize</code> can be used to get the maximum block | The browser will not read a registered buffer upon registration, thus there is no need to re-register after changing the contents of a registered buffer. The buffer will only be read from a crash handler. Registering memory address <code>NULL</code> (zero) will not be allowed, to avoid the issue in which a plugin might register the result of a <code>malloc</code> call without a <code>NULL</code> check. | ||
If the API is called with a key that has already been registered, the new registration will replace the old one. Plugins can attempt to register multiple buffers. | |||
Calling <code>NPN_GetValue</code> with new key <code>NPNVmaxCrashMemoryBlockSize</code> can be used to get the maximum amount of memory available for a plugin's block registration. This is not a per-block or per-instance limit, it is a per-plugin limit. | |||
<pre> | <pre> | ||
| Line 60: | Line 63: | ||
* 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. | ||
Latest revision as of 18:59, 6 June 2011
Status
Under Consideration
Contributors
- Last modified: June 6, 2011
- Authors: Sandeep Akula (Adobe Systems), Vinod Menon (Adobe Systems)
- Contributors: Josh Aas (Mozilla Corporation)
Problem Summary
Currently there are no mechanisms available for browser plug-ins to add plug-in specific data into browser-generated crash reports. Additional information added by browser plug-ins will facilitate easier and faster troubleshooting 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.
Current Proposal
Two new functions for registering and unregistering blocks of memory are added.
NPError NPN_ErrorReportingRegisterMemoryBlock(const char* key,
uint32_t flags,
void* pMemBlock,
size_t sizeOfMemBlock);
Parameters:
key: unique string identifying the memory blockflags:- Future use, no flags defined now.
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 allowedNPERR_INVALID_PARAM: If the registration failsNPERR_NO_ERROR: If successful
Registered buffers must contain textual UTF8/ASCII data which is NULL terminated. Non-textual data can be encoded as text before it is placed in a registered buffer.
The browser will not read a registered buffer upon registration, thus there is no need to re-register after changing the contents of a registered buffer. The buffer will only be read from a crash handler. Registering memory address NULL (zero) will not be allowed, to avoid the issue in which a plugin might register the result of a malloc call without a NULL check.
If the API is called with a key that has already been registered, the new registration will replace the old one. Plugins can attempt to register multiple buffers.
Calling NPN_GetValue with new key NPNVmaxCrashMemoryBlockSize can be used to get the maximum amount of memory available for a plugin's block registration. This is not a per-block or per-instance limit, it is a per-plugin limit.
NPError NPN_ErrorReportingUnregisterMemoryBlock(const char* key);
Parameters:
key: key value which was used to register the memory block
Return value:
NPERR_INVALID_PARAM: invalid memory keyNPERR_GENERIC_ERROR: any generic errorNPERR_NO_ERROR: memory successfully unregistered
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.