369506 - Calling NPN_ReleaseObject() inside of NPP_Destroy() crashes

Status: RESOLVED WORKSFORME

(Core Graveyard :: Plug-ins, defect)

Description

[William Bardwell]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) Gecko/20061206 Firefox/1.5.0.9
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1

If you have a plugin which has some saved the Window object or any object passed in from the JavaScript environment, and you want to clean it up by calling NPN_ReleaseObject(), you can't.  If you call NPN_ReleaseObject() in NPP_Destroy, which is the first time that you know that the plugin needs to cleanup, it
crashes.  I hope that the whole JavaScript environment is being torn down, so this is not a memory leak, but I am not sure.  Calling NPN_ReleaseObject() earlier seems to work fine.

Reproducible: Always

Steps to Reproduce:
1. call NPN_GetValue(inst->npp, NPNVWindowNPObject, &windowObject) and save
that value in some plugin private data.
2. Try to clean it up in NPN_Destroy() (or have another object that has a saved window object, or any object from the javascript environment, and call NPN_ReleaseObject() on that, which then gets 'invalidated' and 'deallocated', but if it calls NPN_ReleaseObject() in either of those methods, it has the same problem.)
3. Get **** off when things crash.


Expected Results:  
You should be able to call NPN_ReleaseObject during invalidate and NPP_Destroy().  Or there should be documentation saying what objects don't need to be released once you hit NPP_Destroy()

Comment 1

[timeless]

i presume this worked in n4?

Comment 2

[Boris Zbarsky [:bzbarsky]]

William, do you happen to have a talkback incident ID number or debug data for the crash?

Comment 3

[timeless]

oops, this is of course a new api, that didn't exist in n4 :)

Comment 4

[William Bardwell]

I have now sent in talkback thingies for this bug from Firefox 2.0.1 and
GranParadiso/3.0a1, but I am having trouble reproducing it in
a Minefield/3.0a2pre from January.

Comment 5

[Boris Zbarsky [:bzbarsky]]

William, what are the incident IDs?  Or some other information you put in them that I could search on?

See http://kb.mozillazine.org/Talkback#Getting_an_incident_ID for instructions on getting the IDs.

Comment 6

[William Bardwell]

TB29081650K and TB29081757W

Comment 7

[Boris Zbarsky [:bzbarsky]]

Hrm.  Yeah, that doesn't get us very far.  The first stack is:

  ntdll.dll + 0x111de (0x7c9111de)

and the second one is:

  ntdll.dll + 0x11f6c (0x7c911f6c)
  MSVCR80.dll + 0x4ce9 (0x60094ce9)
  0x06f06800

Confirming that this does crash; someone will have to try to reproduce this on Windows... :(

Comment 8

[William Bardwell]

Hum...I may have some additional issues, since I am getting "Bad NPObject as
private data!" errors in the Error console even without the code that does a
release.  (This happens when browsing back to a page already in the history,
with JavaScript that tries to set a property in the scriptable object.  But the
scriptable object is fine later on.  This might be a separate and equally
obnoxious bug.)

Comment 9

[Wayne Mery (:wsmwk)]

is bug 374475 a duplicate?

Comment 10

[Boris Zbarsky [:bzbarsky]]

No.

Comment 11

[Benjamin Smedberg]

We have tests for this behavior, and only Flash matters now.