Bug 50548 – Hang when trying to enumerate properties for NPObjects created by Hosted Plugins

• Component: Plug-ins
• Status: RESOLVED WONTFIX

Created attachment 75646 [details]
Replace main.m with this in NetsapeCocoaPlugin example

I apologize if this is not the correct place to post this.

The problem occurs under Safari (5.0.3) when running a 32bit NPAPI plugin.

Steps to reproduce:

- From Javascript, call a function on the plugin.
- In the plugin function create a custom NPObject (with a valid enumerate method)
- From the same plugin function, invoke a Javascript function, passing the custom NPObject as a parameter
- From this invoked Javascript functon, attempt to enumerate the properties of the parameter with something like:

    for (i in pluginObject) {
       ...
    }

Both browser and WebKitPluginHost and the browser process hang.  Equivalently, the Javascript debugger shows the object as 'ProxyRuntimeObject' and hangs when trying to inspect it.  Getting specific properties works fine.

The code dealing with this appears to be in WebKit, which is why I'm submitting this here.  However, I cannot see a way to try this with the latest build.  Chromium appears not to use the WebKitPluginHost functionality.

I have attached a modification of the NetscapeCocoaPlugin main.m which shows the problem.  Build for 32 bit and run with the attached test.html.

If you need further information or if there is a way I can check the ProxyRuntimeObject functionality myself with the latest build then please let me know.

Thanks.

Created attachment 75647 [details]
html file to repro the hang

[Alexey Proskuryakov]

Could you please attach output of sample command on WebKitPluginHost process?

Created attachment 75766 [details]
console.log

Thanks for your reply.  Here is the console output from the WebKitPluginHost process.
The first enumeration calls into Enumerate as expected, and the call from the plugin back into the JS happens, and that's where it freezes.

Let me know if you need any more information.

Here is the call stack from the WebKitPluginHost process when it freezes:

$ gdb --pid 711
GNU gdb 6.3.50-20050815 (Apple version gdb-1472) (Wed Jul 21 10:53:12 UTC 2010)
...
0x931920a6 in __semwait_signal ()
(gdb) bt
#0  0x931920a6 in __semwait_signal ()
#1  0x93191d62 in _pthread_cond_wait ()
#2  0x931939f8 in pthread_cond_wait$UNIX2003 ()
#3  0x16ed31da in .objc_class_name_MenuHandler ()
#4  0x16ed298c in .objc_class_name_MenuHandler ()
#5  0x16eddf20 in .objc_class_name_MenuHandler ()
#6  0x16eddfd0 in .objc_class_name_MenuHandler ()
#7  0x16ed1dd9 in .objc_class_name_MenuHandler ()
#8  0x000e4302 in ScriptableObject::Invoke (npobj=0x410a40, name=0x410750, args=0x413930, argCount=1, result=0xbfffe704) at main.mm:254
#9  0x16ed6981 in .objc_class_name_MenuHandler ()
#10 0x16ed0283 in .objc_class_name_MenuHandler ()
#11 0x9070e531 in __CFRunLoopDoBlocks ()
#12 0x906be9e3 in __CFRunLoopRun ()
#13 0x906bd464 in CFRunLoopRunSpecific ()
#14 0x906bd291 in CFRunLoopRunInMode ()
#15 0x97decf9c in RunCurrentEventLoopInMode ()
#16 0x97decd51 in ReceiveNextEventCommon ()
#17 0x97decbd6 in BlockUntilNextEventMatchingListInMode ()
#18 0x9882878d in _DPSNextEvent ()
#19 0x98827fce in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#20 0x987ea247 in -[NSApplication run] ()
#21 0x16ecd40f in .objc_class_name_MenuHandler ()
#22 0x16ecd04d in .objc_class_name_MenuHandler ()
(gdb) 


All the '.objc_class_name_MenuHandler' entries are suspicious, but you can see it has hung on line 254 of the program (the browser->invokeDefault() line).

The browser process has this callstack:

$ gdb --pid 710
GNU gdb 6.3.50-20050815 (Apple version gdb-1472) (Wed Jul 21 10:53:12 UTC 2010)
...
0x00007fff8868b2da in mach_msg_trap ()
(gdb) bt
#0  0x00007fff8868b2da in mach_msg_trap ()
#1  0x00007fff8868b94d in mach_msg ()
#2  0x00007fff82f70ee4 in WebKit::NetscapePluginHostProxy::processRequests ()
#3  0x00007fff82f70dfc in WebKit::NetscapePluginInstanceProxy::processRequestsAndWaitForReply ()
#4  0x00007fff82fb9add in WebKit::ProxyInstance::getPropertyNames ()
#5  0x00007fff84f6379d in JSC::Bindings::RuntimeObject::getOwnPropertyNames ()
(gdb) 


I hope this helps.

Duncan

[Alexey Proskuryakov]

Anders, this looks like a genuine WebKit/WebKitSystemInterface issue.

Just wanted to ping this ticket to check if you have made any progress with this and see if there is any further information I can provide to help confirm this bug.

It's have rather an impact on us since we are implementing a JavaScript API across several NPObjects, and this is preventing us from fully supporting 64-bit Safari on Mac.

Please let me know if there is anything I can do to help, or if there are any workarounds you are aware of.


Duncan Tebbs

www.turbulenz.com

[Ahmad Saleem]

NPAPI support is removed from Safari 14 onward and it is not supported in Webkit Builds like WebkitGTK as well. I think this can be marked as "RESOLVED WONTFIX". Thanks!

From Comment 01, it seems that issue was happening when running 32-bit NPAPI plugin.

[Ryosuke Niwa]

Yup, won't fix.