bugGnash - The GNU Flash player - Bugs: bug #37077, segfault in...

 
 

bug #37077: segfault in libgnashplugin.so[a85b5000+47000]

Submitter:  Paul Menzel <paulepanter>
Submitted:  Sat 11 Aug 2012 06:45:50 PM UTC
   
 
Category:  plugin Severity:  3 - Normal
Release:  master Status:  Fixed
Privacy:  Public Assigned to:  rsavoye
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 14 Dec 2012 10:41:55 PM UTC, comment #31: 

I would vote for closing it. If it is not fixed, it can be reopened. And I will be apologizing for making false claims.

 Paul Menzel <paulepanter>
Fri 14 Dec 2012 10:38:11 PM UTC, comment #30: 

By the way, this is tracked in the Debian BTS as #686158.


[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686158

 Paul Menzel <paulepanter>
Fri 14 Dec 2012 10:34:32 PM UTC, comment #29: 

Though the segmentation fault happens in `FD_SET(fd, &fdset);` which is called by `readPlayer(_hostfd)`.

[…]
std::string
GnashPluginScriptObject::readPlayer(int fd)
{
//    log_debug(_PRETTY_FUNCTION_);

    std::string empty;

    if (fd <= 0) {
        log_error("Invalid fd passed");
        return empty;
    }

    // Wait for some data from the player
    int bytes = 0;
    fd_set fdset;
    FD_ZERO(&fdset);
    FD_SET(fd, &fdset);
    struct timeval tval;
    tval.tv_sec = 2;
    tval.tv_usec = 0;
    // log_debug("Waiting for data... ");
    if (select(fd+1, &fdset, NULL, NULL, &tval)) {
        // log_debug("There is data in the network");
[…]

So I am pretty certain that the segmentation fault is fixed now.

 Paul Menzel <paulepanter>
Fri 14 Dec 2012 10:27:53 PM UTC, comment #28: 

So I assume I can close this now ?

 Rob Savoye <rsavoye>
Group administrator
Fri 14 Dec 2012 10:26:02 PM UTC, comment #27: 

1. Thank you for committing the patch. May I ask, why you did not take my patch? A more elaborate commit message would have been nice. At least referencing this bug report.

2. I am now pretty convinced that this caused the crashes.
α) libgnashplugin has not crashed ever since applying it.
β) The code checks for -1 in a lot of different places. Not initializing these descriptors violates the assumptions made in these checks.

 Paul Menzel <paulepanter>
Fri 14 Dec 2012 02:26:09 AM UTC, comment #26: 

Patch committed as of #bcd78c4. I don't think this is the cause of the segfault, but good catch. The other constructor was initializing these, but that one was not.

 Rob Savoye <rsavoye>
Group administrator
Thu 13 Dec 2012 09:03:01 AM UTC, comment #25: 

Bastiaan, a little unrelated, but as you have Fedora with Midori 0.4.6 and WebKitGTK+ 1.8.1, could you please  try to play a Flash movie in YouTube? It does not work for me currently.

 Paul Menzel <paulepanter>
Wed 12 Dec 2012 11:15:09 PM UTC, comment #24: 

webkitgtk-1.6.1-1.fc16.i686.rpm
webkitgtk-1.8.1-1.fc17.i686.rpm

(from mirrors under linux/releases/1[67]/Fedora/i386/os/Packages)

 Anonymous
Wed 12 Dec 2012 05:35:42 PM UTC, comment #23: 

Paul: happy to know truth can still emerge, seeking it hard enough ...

Now try harder to get that crash !

 Sandro Santilli <strk>
Group Member
Wed 12 Dec 2012 05:09:38 PM UTC, comment #22: 

Sandro seems to be right. Initializing both variables, Valgrind does not complain anymore and I have not seen crashes. Though it was hard to reproduce, but it looks promising.

 Paul Menzel <paulepanter>
Wed 12 Dec 2012 04:56:49 PM UTC, comment #21: 

Rob, what version of WebKit is fc16 using? Unfortunately I am too dumb to operate Fedora’s Web interface [1].

[1] https://admin.fedoraproject.org/pkgdb/acls/name/webkitgtk#f16

 Paul Menzel <paulepanter>
Wed 12 Dec 2012 02:40:26 PM UTC, comment #20: 

Just to keep things interesting, Midori 0.4.6 (on my fc16 system) works flawlessly, I'm sitting here watching youtube videos with no segfault at all.

 Rob Savoye <rsavoye>
Group administrator
Wed 12 Dec 2012 02:32:06 PM UTC, comment #19: 

I think it is unlikely that the Gnash plugin has memory issues. I still think this is a bug in the NPAPAI emulation in webkit/Midori. That said, it'd probably be a good idea for the plugin to handle this case, and not segfault. I'll see about getting Midori running on my workstation and see if I can reproduce.

 Rob Savoye <rsavoye>
Group administrator
Wed 12 Dec 2012 02:01:16 PM UTC, comment #18: 

I just checked with the Midori developers and they say, Midori does not have anything to do with the NPAPI and WebKit is responsible for that. I am using WebKitGTK+ 1.8.1-3.3.

 Paul Menzel <paulepanter>
Wed 12 Dec 2012 01:42:00 PM UTC, comment #17: 

It's a bug in Midori's NPAPI implementation, not Gnash. The two file descriptors are initialized to -1, as is traditional. They then get a real value when the socket connection to the player is created. This currently works under several different browsers, and several different platforms, if it didn't, everyone woul;d be screaming at us with bug reports.

 Rob Savoye <rsavoye>
Group administrator
Wed 12 Dec 2012 11:51:59 AM UTC, comment #16: 

"supposed to happen" is one thing, "happening" is another.
I've very rarely seen valgrind giving false positive.

Initialize to the same value used in the other constructor (-1).

Once memory error clean it may be easier to debug concepual bugs (as in how HasScripting() && _scriptObject affects later code)

 Sandro Santilli <strk>
Group Member
Wed 12 Dec 2012 11:50:02 AM UTC, comment #15: 

To what values should I initialize the two variables?

 Paul Menzel <paulepanter>
Wed 12 Dec 2012 11:48:59 AM UTC, comment #14: 

Regarding setting `_controlfd` and `_hostfd` them, that is supposed to happen in `plugin/npapi/plugin.cpp`.

NPError
nsPluginInstance::startProc()
{

    int p2c_pipe[2];
    int c2p_pipe[2];
    int p2c_controlpipe[2];

    int ret = socketpair(AF_UNIX, SOCK_STREAM, 0, p2c_pipe);
    if (ret == -1) {
        gnash::log_error("socketpair(p2c) failed: %s", strerror(errno));
        return NPERR_GENERIC_ERROR;
    }
    _streamfd = p2c_pipe[1];

    ret = socketpair(AF_UNIX, SOCK_STREAM, 0, c2p_pipe);
    if (ret == -1) {
        gnash::log_error("socketpair(c2p) failed: %s", strerror(errno));
        return NPERR_GENERIC_ERROR;
    }

    ret = socketpair(AF_UNIX, SOCK_STREAM, 0, p2c_controlpipe);
    if (ret == -1) {
        gnash::log_error("socketpair(control) failed: %s", strerror(errno));
        return NPERR_GENERIC_ERROR;
    }

    if (HasScripting() && _scriptObject) {
        _scriptObject->setControlFD(p2c_controlpipe[1]);
        _scriptObject->setHostFD(c2p_pipe[0]);
    }
   
    // Setup the command line for starting Gnash
[…]
}

 Paul Menzel <paulepanter>
Wed 12 Dec 2012 11:35:36 AM UTC, comment #13: 

It looks to me that this constructor:
GnashPluginScriptObject::GnashPluginScriptObject(NPP npp)

Is not initializing the _hostfd and _controlfd.
Please see if doing so fixes the conditional jump depends on uninitialized value

Sandro Santilli <strk>
Group Member
Wed 12 Dec 2012 11:30:32 AM UTC, comment #12: 

Besides WebKitGTK+ making Valgrind pretty chatty,

        $ G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --tool=memcheck --leak-check=full --leak-resolution=high --num-callers=20 --smc-check=all --error-limit=no --log-file=/tmp/20121212--midori-valgrind.log midori -c /tmp/midori
        WARNING: gnome-keyring:: couldn't connect to: /home/paul/.cache/keyring-rl9Th8/pkcs11: Datei oder Verzeichnis nicht gefunden
        ERROR: Invalid fd passed
        Getötet

I found the pasted messages regarding Gnash. Most of the file descriptors do not seem to get negative when corrupted, so the above message is not seen a lot in Gnash’s log output. But Valgrind catches them.

        $ grep "invalid file" 20121212--midori-valgrind.log
        ==2064== Warning: invalid file descriptor 610044180 in syscall write()
        ==2064== Warning: invalid file descriptor 6094891 in syscall write()
        ==2064== Warning: invalid file descriptor 678457172 in syscall write()
        ==2064== Warning: invalid file descriptor 3670073 in syscall write()

Valgrind messages concerting Gnash.

[…]

==2064== Conditional jump or move depends on uninitialised value(s)
==2064==    at 0x18C9C038: gnash::GnashPluginScriptObject::writePlayer(int, std::string const&) (pluginScriptObject.cpp:688)
==2064==    by 0x18C9C07D: gnash::GnashPluginScriptObject::writePlayer(std::string const&) (pluginScriptObject.cpp:678)
==2064==    by 0x18CA0345: gnash::GnashPluginScriptObject::GetVariable(std::string const&) (pluginScriptObject.cpp:612)
==2064==    by 0x18CA7244: gnash::GetVariableCallback(NPObject*, void*, _NPVariant const*, unsigned int, _NPVariant*) (callbacks.cpp:144)
==2064==    by 0x18C9FC81: gnash::GnashPluginScriptObject::Invoke(NPObject*, void*, _NPVariant const*, unsigned int, _NPVariant*) (pluginScriptObject.cpp:527)
==2064==    by 0x18C9FD22: gnash::GnashPluginScriptObject::marshalInvoke(NPObject*, void*, _NPVariant const*, unsigned int, _NPVariant*) (pluginScriptObject.cpp:346)
==2064==    by 0x5638945: JSC::Bindings::CInstance::invokeMethod(JSC::ExecState*, JSC::RuntimeMethod*) (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x56414C3: JSC::callRuntimeMethod(JSC::ExecState*) (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x6B5AAAA: cti_op_call_NotJSFunction (in /usr/lib/libjavascriptcoregtk-1.0.so.0.13.2)
==2064==    by 0xC3E81D6: ???
==2064==    by 0x6B15589: JSC::Interpreter::executeCall(JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) (in /usr/lib/libjavascriptcoregtk-1.0.so.0.13.2)
==2064==    by 0x6BE4331: JSC::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) (in /usr/lib/libjavascriptcoregtk-1.0.so.0.13.2)
==2064==    by 0x55C0679: WebCore::JSEventListener::handleEvent(WebCore::ScriptExecutionContext*, WebCore::Event*) (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x57663D5: WebCore::EventTarget::fireEventListeners(WebCore::Event*, WebCore::EventTargetData*, WTF::Vector<WebCore::RegisteredEventListener, 1u>&) (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x57665CF: WebCore::EventTarget::fireEventListeners(WebCore::Event*) (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x5A98A19: WebCore::DOMWindow::dispatchEvent(WTF::PassRefPtr<WebCore::Event>, WTF::PassRefPtr<WebCore::EventTarget>) (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x5A9959A: WebCore::DOMWindow::dispatchLoadEvent() (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x572E55D: WebCore::Document::dispatchWindowLoadEvent() (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x5732697: WebCore::Document::implicitClose() (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x5A19353: WebCore::FrameLoader::checkCallImplicitClose() (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)

[…]

==2064== 288 bytes in 24 blocks are definitely lost in loss record 17,134 of 19,142
==2064==    at 0x48288D8: malloc (vg_replace_malloc.c:270)
==2064==    by 0x70A6E1F: strdup (strdup.c:43)
==2064==    by 0x5640328: _NPN_UTF8FromIdentifier (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x18C9AF0E: NPN_UTF8FromIdentifier (npn_gate.cpp:266)
==2064==    by 0x18C9FC1C: gnash::GnashPluginScriptObject::Invoke(NPObject*, void*, _NPVariant const*, unsigned int, _NPVariant*) (pluginScriptObject.cpp:514)
==2064==    by 0x18C9FD22: gnash::GnashPluginScriptObject::marshalInvoke(NPObject*, void*, _NPVariant const*, unsigned int, _NPVariant*) (pluginScriptObject.cpp:346)
==2064==    by 0x5638945: JSC::Bindings::CInstance::invokeMethod(JSC::ExecState*, JSC::RuntimeMethod*) (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x56414C3: JSC::callRuntimeMethod(JSC::ExecState*) (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x6B5AAAA: cti_op_call_NotJSFunction (in /usr/lib/libjavascriptcoregtk-1.0.so.0.13.2)
==2064==    by 0xC3E81D6: ???
==2064==    by 0x6B15589: JSC::Interpreter::executeCall(JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) (in /usr/lib/libjavascriptcoregtk-1.0.so.0.13.2)
==2064==    by 0x6BE4331: JSC::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) (in /usr/lib/libjavascriptcoregtk-1.0.so.0.13.2)
==2064==    by 0x55C0679: WebCore::JSEventListener::handleEvent(WebCore::ScriptExecutionContext*, WebCore::Event*) (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x57663D5: WebCore::EventTarget::fireEventListeners(WebCore::Event*, WebCore::EventTargetData*, WTF::Vector<WebCore::RegisteredEventListener, 1u>&) (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x57665CF: WebCore::EventTarget::fireEventListeners(WebCore::Event*) (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x5A98A19: WebCore::DOMWindow::dispatchEvent(WTF::PassRefPtr<WebCore::Event>, WTF::PassRefPtr<WebCore::EventTarget>) (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x5A9959A: WebCore::DOMWindow::dispatchLoadEvent() (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x572E55D: WebCore::Document::dispatchWindowLoadEvent() (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x5732697: WebCore::Document::implicitClose() (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x5A19353: WebCore::FrameLoader::checkCallImplicitClose() (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)

[…]

==2064== Syscall param write(fd) contains uninitialised byte(s)
==2064==    at 0x70212BB: ??? (syscall-template.S:82)
==2064==    by 0x18C9C052: gnash::GnashPluginScriptObject::writePlayer(int, std::string const&) (pluginScriptObject.cpp:689)
==2064==    by 0x18C9C07D: gnash::GnashPluginScriptObject::writePlayer(std::string const&) (pluginScriptObject.cpp:678)
==2064==    by 0x18CA0345: gnash::GnashPluginScriptObject::GetVariable(std::string const&) (pluginScriptObject.cpp:612)
==2064==    by 0x18CA7244: gnash::GetVariableCallback(NPObject*, void*, _NPVariant const*, unsigned int, _NPVariant*) (callbacks.cpp:144)
==2064==    by 0x18C9FC81: gnash::GnashPluginScriptObject::Invoke(NPObject*, void*, _NPVariant const*, unsigned int, _NPVariant*) (pluginScriptObject.cpp:527)
==2064==    by 0x18C9FD22: gnash::GnashPluginScriptObject::marshalInvoke(NPObject*, void*, _NPVariant const*, unsigned int, _NPVariant*) (pluginScriptObject.cpp:346)
==2064==    by 0x5638945: JSC::Bindings::CInstance::invokeMethod(JSC::ExecState*, JSC::RuntimeMethod*) (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x56414C3: JSC::callRuntimeMethod(JSC::ExecState*) (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x6B5AAAA: cti_op_call_NotJSFunction (in /usr/lib/libjavascriptcoregtk-1.0.so.0.13.2)
==2064==    by 0xC3E81D6: ???
==2064==    by 0x6B15589: JSC::Interpreter::executeCall(JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) (in /usr/lib/libjavascriptcoregtk-1.0.so.0.13.2)
==2064==    by 0x6BE4331: JSC::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) (in /usr/lib/libjavascriptcoregtk-1.0.so.0.13.2)
==2064==    by 0x55C0679: WebCore::JSEventListener::handleEvent(WebCore::ScriptExecutionContext*, WebCore::Event*) (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x57663D5: WebCore::EventTarget::fireEventListeners(WebCore::Event*, WebCore::EventTargetData*, WTF::Vector<WebCore::RegisteredEventListener, 1u>&) (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x57665CF: WebCore::EventTarget::fireEventListeners(WebCore::Event*) (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x5A98A19: WebCore::DOMWindow::dispatchEvent(WTF::PassRefPtr<WebCore::Event>, WTF::PassRefPtr<WebCore::EventTarget>) (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x5A9959A: WebCore::DOMWindow::dispatchLoadEvent() (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x572E55D: WebCore::Document::dispatchWindowLoadEvent() (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x5732697: WebCore::Document::implicitClose() (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)

[…]

==2064== Invalid read of size 4
==2064==    at 0x18C9F8D3: gnash::GnashPluginScriptObject::readPlayer(int) (pluginScriptObject.cpp:717)
==2064==    by 0x196FFBBF: ???
==2064==  Address 0xbf21e770 is not stack'd, malloc'd or (recently) free'd

[…]

==2064== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==2064==  Access not within mapped region at address 0xBF21E770
==2064==    at 0x18C9F8D3: gnash::GnashPluginScriptObject::readPlayer(int) (pluginScriptObject.cpp:717)
==2064==    by 0x196FFBBF: ???
==2064==  If you believe this happened as a result of a stack
==2064==  overflow in your program's main thread (unlikely but
==2064==  possible), you can try to increase the size of the
==2064==  main thread stack using the --main-stacksize= flag.
==2064==  The main thread stack size used in this run was 8388608.
==2064==
==2064== HEAP SUMMARY:
==2064==     in use at exit: 10,052,457 bytes in 83,872 blocks
==2064==   total heap usage: 4,785,904 allocs, 4,702,032 frees, 309,790,306 bytes allocated

[…]

==2064== 12 bytes in 1 blocks are definitely lost in loss record 4,525 of 19,142
==2064==    at 0x48288D8: malloc (vg_replace_malloc.c:270)
==2064==    by 0x70A6E1F: strdup (strdup.c:43)
==2064==    by 0x5640328: _NPN_UTF8FromIdentifier (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x18C9AF0E: NPN_UTF8FromIdentifier (npn_gate.cpp:266)
==2064==    by 0x18C9FC1C: gnash::GnashPluginScriptObject::Invoke(NPObject*, void*, _NPVariant const*, unsigned int, _NPVariant*) (pluginScriptObject.cpp:514)
==2064==    by 0x18C9FD22: gnash::GnashPluginScriptObject::marshalInvoke(NPObject*, void*, _NPVariant const*, unsigned int, _NPVariant*) (pluginScriptObject.cpp:346)
==2064==    by 0x5638945: JSC::Bindings::CInstance::invokeMethod(JSC::ExecState*, JSC::RuntimeMethod*) (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x56414C3: JSC::callRuntimeMethod(JSC::ExecState*) (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x6B5AAAA: cti_op_call_NotJSFunction (in /usr/lib/libjavascriptcoregtk-1.0.so.0.13.2)
==2064==    by 0xC3E81D6: ???
==2064==    by 0x6B15589: JSC::Interpreter::executeCall(JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) (in /usr/lib/libjavascriptcoregtk-1.0.so.0.13.2)
==2064==    by 0x6BE4331: JSC::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) (in /usr/lib/libjavascriptcoregtk-1.0.so.0.13.2)
==2064==    by 0x55C0679: WebCore::JSEventListener::handleEvent(WebCore::ScriptExecutionContext*, WebCore::Event*) (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x57663D5: WebCore::EventTarget::fireEventListeners(WebCore::Event*, WebCore::EventTargetData*, WTF::Vector<WebCore::RegisteredEventListener, 1u>&) (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x57665CF: WebCore::EventTarget::fireEventListeners(WebCore::Event*) (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x577084D: WebCore::Node::handleLocalEvents(WebCore::Event*) (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x9E2DFFF: ???
==2064==
==2064== 12 bytes in 1 blocks are definitely lost in loss record 4,526 of 19,142
==2064==    at 0x48288D8: malloc (vg_replace_malloc.c:270)
==2064==    by 0x70A6E1F: strdup (strdup.c:43)
==2064==    by 0x5640328: _NPN_UTF8FromIdentifier (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x18C9AF0E: NPN_UTF8FromIdentifier (npn_gate.cpp:266)
==2064==    by 0x18C9FC1C: gnash::GnashPluginScriptObject::Invoke(NPObject*, void*, _NPVariant const*, unsigned int, _NPVariant*) (pluginScriptObject.cpp:514)
==2064==    by 0x18C9FD22: gnash::GnashPluginScriptObject::marshalInvoke(NPObject*, void*, _NPVariant const*, unsigned int, _NPVariant*) (pluginScriptObject.cpp:346)
==2064==    by 0x5638945: JSC::Bindings::CInstance::invokeMethod(JSC::ExecState*, JSC::RuntimeMethod*) (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x56414C3: JSC::callRuntimeMethod(JSC::ExecState*) (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x6B5AAAA: cti_op_call_NotJSFunction (in /usr/lib/libjavascriptcoregtk-1.0.so.0.13.2)
==2064==    by 0xC3E81D6: ???
==2064==    by 0x6B15589: JSC::Interpreter::executeCall(JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) (in /usr/lib/libjavascriptcoregtk-1.0.so.0.13.2)
==2064==    by 0x6BE4331: JSC::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) (in /usr/lib/libjavascriptcoregtk-1.0.so.0.13.2)
==2064==    by 0x55C0679: WebCore::JSEventListener::handleEvent(WebCore::ScriptExecutionContext*, WebCore::Event*) (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x57663D5: WebCore::EventTarget::fireEventListeners(WebCore::Event*, WebCore::EventTargetData*, WTF::Vector<WebCore::RegisteredEventListener, 1u>&) (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x57665CF: WebCore::EventTarget::fireEventListeners(WebCore::Event*) (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x577084D: WebCore::Node::handleLocalEvents(WebCore::Event*) (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==2064==    by 0x1713A19F: ???

[…]

==2064== LEAK SUMMARY:
==2064==    definitely lost: 69,200 bytes in 1,951 blocks
==2064==    indirectly lost: 74,805 bytes in 3,552 blocks
==2064==      possibly lost: 618,408 bytes in 6,933 blocks
==2064==    still reachable: 9,290,044 bytes in 71,436 blocks
==2064==         suppressed: 0 bytes in 0 blocks
==2064== Reachable blocks (those to which a pointer was found) are not shown.
==2064== To see them, rerun with: --leak-check=full --show-reachable=yes
==2064==
==2064== For counts of detected and suppressed errors, rerun with: -v
==2064== Use --track-origins=yes to see where uninitialised values come from
==2064== ERROR SUMMARY: 48146 errors from 11270 contexts (suppressed: 411 from 14)

 Paul Menzel <paulepanter>
Wed 12 Dec 2012 11:22:53 AM UTC, comment #11: 

$ egrep -n '_(host|control)fd ='
pluginScriptObject.cpp:647:    _controlfd = x;              // FIXME: this should go away
pluginScriptObject.cpp:662:    _hostfd = x;              // FIXME: this should go away

Sandro Santilli <strk>
Group Member
Wed 12 Dec 2012 11:15:54 AM UTC, comment #10: 

Sandro, thanks for your quick reply. I am going to supply the Valgrind messages in a moment. But could you please enlighten me, how `_controlfd` and `_hostfd` are supposed to be set?

 Paul Menzel <paulepanter>
Wed 12 Dec 2012 10:04:41 AM UTC, comment #9: 

I think it is very likely for the gnash plugin to have memory issues, Valgrind usually helps at figuring that out. Can you try that ?

 Sandro Santilli <strk>
Group Member
Wed 12 Dec 2012 09:58:00 AM UTC, comment #8: 

Ok, looking at the backtrace again,

        #0  0xa79488d3 in gnash::GnashPluginScriptObject::readPlayer (this=this@entry=0xa67e2168, fd=6881392)
            at ../../../plugin/npapi/pluginScriptObject.cpp:717
        #1  0xa7948b2f in gnash::GnashPluginScriptObject::readPlayer (this=0xa67e2168) at ../../../plugin/npapi/pluginScriptObject.cpp:698
        #2  0xb317d5f4 in ?? () from /usr/lib/i386-linux-gnu/libstdc++.so.6
        Backtrace stopped: previous frame inner to this frame (corrupt stack?)

the method(?)/function(?) is called by Gnash’s own `gnash::GnashPluginScriptObject::readPlayer`.

        std::string
        GnashPluginScriptObject::readPlayer()
        {
            return readPlayer(_hostfd);
        }

This uses the variable `_hostfd` which is a class variable(?) and managed by Gnash.

The constructor reads

        // Constructor
        GnashPluginScriptObject::GnashPluginScriptObject()
            : _nppinstance (0),
              _controlfd(-1),
              _hostfd(-1)
        {
        //    log_debug(_PRETTY_FUNCTION_);
           
            initializeIdentifiers();
           
        }

so `_hostfd` is set to `-1` by default. `hostfd_` is not manipulated afterward in that class. But it has to be, as it is set to some high value when the segmentation fault happens.

Could you shed some more light on this, please? From the analysis above, I think now it is indeed a Gnash problem.

 Paul Menzel <paulepanter>
Fri 02 Nov 2012 09:37:19 PM UTC, comment #7: 

Hi. Thanks for all your replies.

From the backtrace, could you add a check which returns some error code(?) – I do not know the code – so that the library does not crash?

 Paul Menzel <paulepanter>
Fri 02 Nov 2012 05:34:26 PM UTC, comment #6: 

I think it's entirely possible the problem is caused by Midori's NPAPI implementation.

 Rob Savoye <rsavoye>
Group administrator
Sat 27 Oct 2012 11:52:19 AM UTC, comment #5: 

Am Samstag, den 27.10.2012, 11:10 +0000 schrieb Bastiaan Jacques:
Follow-up Comment #4, bug #37077 (project gnash):

>
> > 1. What version of Midori do you run? I am using a self-build from latest
> Git.
>
> midori-0.4.6-1.fc17.x86_64
>
> > 2. Did you open like 20 tabs from Phoronix. That triggers this
> > usually in my case.
>
> Yes, lots of Flash activity seems to make it more likely to happen.
>

Sorry, if you have mentioned it already. But it does not segfault for you, does it?

> 4. Any idea what I can do to provide more information to analyze the stack
> > corruption.
>
> Not really. When faced with memory corruption problems I normally use Valgrind
> to find where the problem starts, but running Midori in Valgrind leads to an
> early segfault on my system before we get to any Flash content.


There seem to be some packages for Fedora with 0.4.7. Maybe that works better.

I tried that today and it did not segfault for me.

G_SLICE=always-malloc valgrind --track-origins=yes --leak-check=full --num-callers=50 midori --plain http://phoronix.com/
       
But even after an hour nothing of the site was displayed and nothing related to `gnash` was mentioned in its output.

> 5. Should not the library/plugin return an error instead of segfaulting?
>
> Absolutely. It is possible though that the segfault is ultimately caused by
> Midori due to a bug in their NPAPI implementation, though.


That might be true too.

 Paul Menzel <paulepanter>
Sat 27 Oct 2012 11:10:14 AM UTC, comment #4: 


> 1. What version of Midori do you run? I am using a self-build from latest Git.


midori-0.4.6-1.fc17.x86_64

> 2. Did you open like 20 tabs from Phoronix. That triggers this usually in my case.


Yes, lots of Flash activity seems to make it more likely to happen.

> 4. Any idea what I can do to provide more information to analyze the stack corruption.


Not really. When faced with memory corruption problems I normally use Valgrind to find where the problem starts, but running Midori in Valgrind leads to an early segfault on my system before we get to any Flash content.

> 5. Should not the library/plugin return an error instead of segfaulting?


Absolutely. It is possible though that the segfault is ultimately caused by Midori due to a bug in their NPAPI implementation, though.

 Bastiaan Jacques <bjacques>
Group Member
Sat 27 Oct 2012 10:36:53 AM UTC, comment #3: 

Bastiaan, thanks for the follow up.

1. What version of Midori do you run? I am using a self-build from latest Git.

9efda4447d34a07e91e43c07eb6e5ff43de63572

I do not see these error messages anymore.

2. Did you open like 20 tabs from Phoronix. That triggers this usually in my case.

3. I forgot to mention that I configured the plugin to not start executing the SWF.

$ grep start ~/.gnashpluginrc
set startStopped true

4. Any idea what I can do to provide more information to analyze the stack corruption.

5. Should not the library/plugin return an error instead of segfaulting?

 Paul Menzel <paulepanter>
Thu 25 Oct 2012 11:54:16 PM UTC, comment #2: 

I've been running Midori for a bit to see if I can reproduce the issue. Unfortunately the stack trace below is not especially useful, probably due to stack corruption. We can be sure that fd=1073741824 is not legitimate.

As I was running Midor I saw several error messages also related to file descriptors, such as:

ERROR: Invalid fd passed

Which makes it pretty certain some corruption is going on.

 Bastiaan Jacques <bjacques>
Group Member
Tue 04 Sep 2012 08:29:07 AM UTC, comment #1: 

I can reproduce this reliably. The last time the following was printed to the terminal too.

(gtk-gnash:22055): Gdk-WARNING **: GdkWindow 0x2000003 unexpectedly destroyed

(gtk-gnash:22055): Gtk-CRITICAL **: IA__gtk_style_detach: assertion `style->attach_count > 0' failed
The program 'gtk-gnash' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
  (Details: serial 198 error_code 3 request_code 18 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

[2]+  Speicherzugriffsfehler  (Speicherabzug geschrieben) midori

$ dmesg
[…]
[ 4280.362079] midori[10723]: segfault at 154ea64 ip 00000000e1b1e8d3 sp 00000000ff94ea10 error 6 in libgnashplugin.so[e1afa000+47000]

 Paul Menzel <paulepanter>
Sat 11 Aug 2012 06:45:50 PM UTC, original submission:  

Debian Sid/unstable is running with the following.

    browser-plugin-gnash                          0.8.11~git20120629-1

Using Midori and opening several phoronix.com pages in tabs which use flash advertisement a lot, Midori crashes.

    midori[8497]: segfault at c7ebc150 ip a85d98d3 sp bfebc100 error 7 in libgnashplugin.so[a85b5000+47000]

The was able to capture a core dump and running GDB on it(?) I got the following back trace.

Thread 1 (Thread 0xb2fb9890 (LWP 8497)):
#0  0xa85d98d3 in gnash::GnashPluginScriptObject::readPlayer (this=this@entry=0xa6d7d1f8, fd=1073741824)
    at ../../../plugin/npapi/pluginScriptObject.cpp:717
        empty = {static npos = <optimized out>,
          _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>},
            _M_p = 0xb321f600 ""}}
        bytes = 0
        buf = {static npos = <optimized out>,
          _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>},
            _M_p = 0x8c7141e0 "\310Gq\214\b"}}
        ret = <optimized out>
        fdset = {fds_bits = {0 <repeats 32 times>}}
        tval = {tv_sec = -1289619980, tv_usec = -1255882181}
#1  0xa85d9b2f in gnash::GnashPluginScriptObject::readPlayer (this=0xa6d7d1f8) at ../../../plugin/npapi/pluginScriptObject.cpp:698
No locals.
#2  0xb321f5f4 in ?? () from /usr/lib/i386-linux-gnu/libstdc++.so.6
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Even if Midori is doing something wrong here the library should never segfault!

Please tell me if you need more information.

 Paul Menzel <paulepanter>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #27086:  0001-plugin-npapi-pluginScriptObject.cpp-Initialize-_cont.patch added by paulepanter (3KiB - application/octet-stream - Please apply this patch.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by strk (Posted a comment)
  • -email is unavailable- added by rsavoye (Updated the item)
  • -email is unavailable- added by bjacques (Posted a comment)
  • -email is unavailable- added by paulepanter (Submitted the item)

    •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-12-14 rsavoye StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2012-12-14 rsavoye StatusIn Progress Ready For Test
    2012-12-14 rsavoye StatusWorks For Me In Progress
    2012-12-12 paulepanter Attached File- Added 0001-plugin-npapi-pluginScriptObject.cpp-Initialize-_cont.patch, #27086
    2012-12-12 rsavoye Assigned toNone rsavoye
    2012-12-12 rsavoye Severity4 - Important 3 - Normal
        StatusNone Works For Me
    2012-12-12 strk Severity3 - Normal 4 - Important
        StatusWorks For Me None
    2012-11-02 rsavoye StatusNone Works For Me

    Back to the top

    Copyright © 2024 Free Software Foundation, Inc.
    Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
    The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team.
    Page source code

    Powered by Savane 3.14-d582.
    Corresponding source code