Bug 360891

Summary: (Multithread initialization) Flash player fails when wrapped, works better natively
Product: [Fedora] Fedora Reporter: Julian Sikorski <belegdol>
Component: nspluginwrapperAssignee: Martin Stransky <stransky>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhideCC: belfrancis2001, brentrbrian, caillon, djuran, drago01, fortran, gajownik, gerrit.slomma, rngadam, thesource, timjowers, t.matsuu, tmraz, torsten, tuju, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 0.9.91.5-15.fc8 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-01-07 01:27:22 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 221356    
Attachments:
Description Flags
valgrind --tool=memcheck --leak-check=no --freelist-vol=100000000 --log-file=/tmp/flash $NPW_VIEWER_DIR/npviewer.bin ${1+"$@"}
none
Bug buddy bug report
none
npviewer backtrace
none
Bug Buddy's generated npviewer.bin bug report
none
npviewer.bin report after viewing flash video. none

Description Julian Sikorski 2007-10-31 20:02:33 UTC
Description of problem:
I am encountering many pages which cause the wrapped flash plugin to fail
instantly. To name a few:
http://www.speedtest.net
http://www.enemyterritory.com
http://www.playmobile.pl
All of the above work perfectly fine using unwrapped flash on f7/i386 (my other
box).

Version-Release number of selected component (if applicable):
nspluginwrapper-0.9.91.5-8.fc8.i386
nspluginwrapper-0.9.91.5-8.fc8.x86_64
flash-plugin-9.0.64.0-release.i386
firefox-2.0.0.8-1.fc8.x86_64

How reproducible:
always

Steps to Reproduce:
1. Install rawhide
2. Install flash plugin and nspluginwrapper
3. Visit any of the mentioned pages
  
Actual results:
Wrapped plugin fails miserably

Expected results:
User is able to browse the pages

Additional info:
Since in Fedora 8 all plugins are going to be wrapped, it would be nice to at
least build firefox-32 for f8 until this issue is resolved, at least to allow
figuring out the guilty one (wrapper/plugin) more easily and to allow the users
to access some pages at all.

Comment 1 Julian Sikorski 2007-10-31 21:03:42 UTC
Looks like npviewer.bin is crashing. I hava managed to get the backtrace by
opening youtube.com, attaching to npviewer.bin process and then opening
enemyterritory.com in a new tab:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 4132391824 (LWP 30332)]
IA__g_slice_alloc (mem_size=8) at gslice.c:474
474           (*magazine_chunks)->data = chunk->next;
(gdb) bt
#0  IA__g_slice_alloc (mem_size=8) at gslice.c:474
#1  0x0014b872 in IA__g_slist_prepend (list=0x81168d8, data=0x80ca4c8)
    at gslist.c:91
#2  0x004183bc in g_object_constructor (type=135020136, 
    n_construct_properties=8, construct_params=0x810f670)
    at gobjectnotifyqueue.c:154
#3  0x004163eb in IA__g_object_newv (object_type=135020136, n_parameters=8, 
    parameters=0x810f490) at gobject.c:937
#4  0x00417038 in IA__g_object_new_valist (object_type=135020136, 
    first_property_name=0x5aff48 "colorspace", var_args=0xf64f3fb4 "")
    at gobject.c:1027
#5  0x00417140 in IA__g_object_new (object_type=135020136, 
    first_property_name=0x5aff48 "colorspace") at gobject.c:795
#6  0x005a1384 in IA__gdk_pixbuf_new_from_data (data=0x81e4d98 "", 
    colorspace=GDK_COLORSPACE_RGB, has_alpha=1, bits_per_sample=8, width=477, 
    height=78, rowstride=1908, destroy_fn=0x59f2a0 <free_buffer>, 
    destroy_fn_data=0x0) at gdk-pixbuf-data.c:65
#7  0x0059f17a in IA__gdk_pixbuf_new (colorspace=GDK_COLORSPACE_RGB, 
    has_alpha=1, bits_per_sample=8, width=477, height=78) at gdk-pixbuf.c:273
#8  0xf7842dfa in g_free () at gmem.c:183
#9  0xf7843267 in g_free () at gmem.c:183
#10 0xf780c7e2 in g_free () at gmem.c:183
#11 0xf7966325 in g_free () at gmem.c:183
#12 0xf786da2d in g_free () at gmem.c:183
#13 0x00d6350b in start_thread () from /lib/libpthread.so.0
#14 0x00ccfb2e in clone () from /lib/libc.so.6
(gdb) bt full
#0  IA__g_slice_alloc (mem_size=8) at gslice.c:474
        tmem = (ThreadMemory *) 0x80815c0
        ix = 0
        chunk_size = <value optimized out>
        mem = <value optimized out>
        acat = <value optimized out>
#1  0x0014b872 in IA__g_slist_prepend (list=0x81168d8, data=0x80ca4c8)
    at gslist.c:91
No locals.
#2  0x004183bc in g_object_constructor (type=135020136, 
    n_construct_properties=8, construct_params=0x810f670)
    at gobjectnotifyqueue.c:154
        value = (GValue *) 0x810f4ac
        pspec = <value optimized out>
        nqueue = (GObjectNotifyQueue *) 0x80bf6d0
        object = (GObject *) 0x810f900
#3  0x004163eb in IA__g_object_newv (object_type=135020136, n_parameters=8, 
    parameters=0x810f490) at gobject.c:937
        value = (GValue *) 0x810f53c
        pspec = (GParamSpec *) 0x808a878
        nqueue = <value optimized out>
        object = <value optimized out>
        class = (GObjectClass *) 0x80df9b8
        unref_class = (GObjectClass *) 0x0
        slist = <value optimized out>
        n_total_cparams = 8
        n_cparams = 8
        n_oparams = 0
        n_cvalues = 0
        clist = (GList *) 0x0
        i = 8
        __PRETTY_FUNCTION__ = "IA__g_object_newv"
#4  0x00417038 in IA__g_object_new_valist (object_type=135020136, 
    first_property_name=0x5aff48 "colorspace", var_args=0xf64f3fb4 "")
    at gobject.c:1027
        error = (gchar *) 0x0
        pspec = (GParamSpec *) 0x808a878
        params = (GParameter *) 0x810f490
        name = <value optimized out>
        object = <value optimized out>
        n_params = 8
        n_alloced_params = 16
        __PRETTY_FUNCTION__ = "IA__g_object_new_valist"
#5  0x00417140 in IA__g_object_new (object_type=135020136, 
    first_property_name=0x5aff48 "colorspace") at gobject.c:795
        var_args = 0xf64f3f78 ""
        __PRETTY_FUNCTION__ = "IA__g_object_new"
#6  0x005a1384 in IA__gdk_pixbuf_new_from_data (data=0x81e4d98 "", 
    colorspace=GDK_COLORSPACE_RGB, has_alpha=1, bits_per_sample=8, width=477, 
    height=78, rowstride=1908, destroy_fn=0x59f2a0 <free_buffer>, 
    destroy_fn_data=0x0) at gdk-pixbuf-data.c:65
        pixbuf = <value optimized out>
        __PRETTY_FUNCTION__ = "IA__gdk_pixbuf_new_from_data"
#7  0x0059f17a in IA__gdk_pixbuf_new (colorspace=GDK_COLORSPACE_RGB, 
    has_alpha=1, bits_per_sample=8, width=477, height=78) at gdk-pixbuf.c:273
        channels = <value optimized out>
        rowstride = <value optimized out>
        bytes = <value optimized out>
        __PRETTY_FUNCTION__ = "IA__gdk_pixbuf_new"
#8  0xf7842dfa in g_free () at gmem.c:183
No symbol table info available.
#9  0xf7843267 in g_free () at gmem.c:183
No symbol table info available.
#10 0xf780c7e2 in g_free () at gmem.c:183
No symbol table info available.
#11 0xf7966325 in g_free () at gmem.c:183
No symbol table info available.
#12 0xf786da2d in g_free () at gmem.c:183
No symbol table info available.
#13 0x00d6350b in start_thread () from /lib/libpthread.so.0
No locals.
#14 0x00ccfb2e in clone () from /lib/libc.so.6
        fstab_state = {fs_fp = 0x0, fs_buffer = 0x0, fs_mntres = {
    mnt_fsname = 0x0, mnt_dir = 0x0, mnt_type = 0x0, mnt_opts = 0x0, 
    mnt_freq = 0, mnt_passno = 0}, fs_ret = {fs_spec = 0x0, fs_file = 0x0, 
    fs_vfstype = 0x0, fs_mntops = 0x0, fs_type = 0x0, fs_freq = 0, 
    fs_passno = 0}}
        __elf_set___libc_subfreeres_element_fstab_free__ = (
    const void *) 0xd0f9a0
(gdb)

Comment 2 Julian Sikorski 2007-10-31 21:25:04 UTC
I just confirmed that unwrapped flash works for under f8 as well.

Comment 3 Julian Sikorski 2007-11-01 11:41:27 UTC
Following Warren's suggestion, I rebuilt the mentioned packages under Fedora
7/i386 to eliminate gtk2/glib2 as a source of the problem. There was no
difference, mentioned pages still bring the wrapper down. Attaching the
backtrace for reference.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208366384 (LWP 31626)]
0x00b6ea6d in IA__g_type_check_value (value=0x95414a8) at gtype.c:3238
3238      if (node && node->mutatable_check_cache)
(gdb) bt
#0  0x00b6ea6d in IA__g_type_check_value (value=0x95414a8) at gtype.c:3238
#1  0x00b74012 in IA__g_value_unset (value=0x95414a8) at gvalue.c:150
#2  0x00b57bfe in IA__g_object_newv (object_type=156002240, n_parameters=8, 
    parameters=0x9526d10) at gobject.c:941
#3  0x00b587d8 in IA__g_object_new_valist (object_type=156002240, 
    first_property_name=0xc6c888 "colorspace", var_args=0xbf9110b4 "")
    at gobject.c:1022
#4  0x00b588e0 in IA__g_object_new (object_type=156002240, 
    first_property_name=0xc6c888 "colorspace") at gobject.c:795
#5  0x00c60364 in IA__gdk_pixbuf_new_from_data (data=0x95b2eb0 "\bmR\tP�i", 
    colorspace=GDK_COLORSPACE_RGB, has_alpha=1, bits_per_sample=8, width=288, 
    height=49, rowstride=1152, destroy_fn=0xc5e590 <free_buffer>, 
    destroy_fn_data=0x0) at gdk-pixbuf-data.c:65
#6  0x00c5e46a in IA__gdk_pixbuf_new (colorspace=GDK_COLORSPACE_RGB, 
    has_alpha=1, bits_per_sample=8, width=288, height=49) at gdk-pixbuf.c:273
#7  0x00ebbdd0 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
#8  0x00ebc267 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
#9  0x00e857e2 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
#10 0x00e6c9a0 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
#11 0x00e9b620 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
#12 0x00e9c2d0 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
#13 0x00e9c62e in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
#14 0x011ab1f0 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
#15 0x011aa9fb in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
#16 0x00e9c0cf in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
#17 0x00e9c62e in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
#18 0x011ab1f0 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
#19 0x011aa9fb in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
#20 0x011abd2d in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
#21 0x011aa9fb in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
#22 0x011abd2d in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
#23 0x011aa9fb in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
#24 0x011abd2d in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
#25 0x0111786b in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
#26 0x0111b57a in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
#27 0x01237a02 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
#28 0x0123bd08 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
#29 0x0123bee5 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
#30 0x00de74ed in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
#31 0x01246eaf in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
#32 0x00ec264b in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
#33 0x00de6e0e in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
#34 0x00a94dc6 in g_timeout_dispatch (source=0x9526810, callback=0, 
    user_data=0xb7270000) at gmain.c:3422
#35 0x00a947f2 in IA__g_main_context_dispatch (context=0x94d2ba0)
    at gmain.c:2045
#36 0x00a977cf in g_main_context_iterate (context=0x94d2ba0, block=1, 
    dispatch=1, self=0x94d5ff0) at gmain.c:2677
#37 0x00a97b79 in IA__g_main_loop_run (loop=0x94d3b10) at gmain.c:2881
#38 0x0231af44 in IA__gtk_main () at gtkmain.c:1154
#39 0x08050602 in main (argc=<value optimized out>, argv=0xbf9136f4)
    at ../src/npw-viewer.c:3222
#40 0x0055ff70 in __libc_start_main (main=0x804fe80 <main>, argc=5, 
    ubp_av=0xbf9136f4, init=0x805d890 <__libc_csu_init>, 
    fini=0x805d880 <__libc_csu_fini>, rtld_fini=0x5353d0 <_dl_fini>, 
    stack_end=0xbf9136ec) at libc-start.c:222
#41 0x0804a631 in _start ()
(gdb) bt full
#0  0x00b6ea6d in IA__g_type_check_value (value=0x95414a8) at gtype.c:3238
No locals.
#1  0x00b74012 in IA__g_value_unset (value=0x95414a8) at gvalue.c:150
        value_table = <value optimized out>
        __PRETTY_FUNCTION__ = "IA__g_value_unset"
#2  0x00b57bfe in IA__g_object_newv (object_type=156002240, n_parameters=8, 
    parameters=0x9526d10) at gobject.c:941
        value = <value optimized out>
        pspec = <value optimized out>
        nqueue = <value optimized out>
        object = (GObject *) 0x9573d00
        class = (GObjectClass *) 0x94fda70
        unref_class = (GObjectClass *) 0x0
        slist = <value optimized out>
        n_total_cparams = 8
        n_cparams = 2
        n_oparams = 0
        n_cvalues = 6
        clist = (GList *) 0x0
        i = 8
        __PRETTY_FUNCTION__ = "IA__g_object_newv"
#3  0x00b587d8 in IA__g_object_new_valist (object_type=156002240, 
    first_property_name=0xc6c888 "colorspace", var_args=0xbf9110b4 "")
    at gobject.c:1022
        error = (gchar *) 0x0
        pspec = (GParamSpec *) 0x94c8678
        params = (GParameter *) 0x9526d10
        name = <value optimized out>
        object = <value optimized out>
        n_params = 8
        n_alloced_params = 16
        __PRETTY_FUNCTION__ = "IA__g_object_new_valist"
#4  0x00b588e0 in IA__g_object_new (object_type=156002240, 
    first_property_name=0xc6c888 "colorspace") at gobject.c:795
        var_args = 0xbf911078 ""
        __PRETTY_FUNCTION__ = "IA__g_object_new"
#5  0x00c60364 in IA__gdk_pixbuf_new_from_data (data=0x95b2eb0 "\bmR\tP�i", 
    colorspace=GDK_COLORSPACE_RGB, has_alpha=1, bits_per_sample=8, width=288, 
    height=49, rowstride=1152, destroy_fn=0xc5e590 <free_buffer>, 
    destroy_fn_data=0x0) at gdk-pixbuf-data.c:65
        pixbuf = <value optimized out>
        __PRETTY_FUNCTION__ = "IA__gdk_pixbuf_new_from_data"
#6  0x00c5e46a in IA__gdk_pixbuf_new (colorspace=GDK_COLORSPACE_RGB, 
    has_alpha=1, bits_per_sample=8, width=288, height=49) at gdk-pixbuf.c:273
        channels = <value optimized out>
        rowstride = <value optimized out>
        bytes = <value optimized out>
        __PRETTY_FUNCTION__ = "IA__gdk_pixbuf_new"
#7  0x00ebbdd0 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
No symbol table info available.
#8  0x00ebc267 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
No symbol table info available.
#9  0x00e857e2 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
No symbol table info available.
#10 0x00e6c9a0 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
No symbol table info available.
#11 0x00e9b620 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
No symbol table info available.
#12 0x00e9c2d0 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
No symbol table info available.
#13 0x00e9c62e in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
No symbol table info available.
#14 0x011ab1f0 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
No symbol table info available.
#15 0x011aa9fb in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
No symbol table info available.
#16 0x00e9c0cf in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
No symbol table info available.
#17 0x00e9c62e in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
No symbol table info available.
#18 0x011ab1f0 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
No symbol table info available.
#19 0x011aa9fb in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
No symbol table info available.
#20 0x011abd2d in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
No symbol table info available.
#21 0x011aa9fb in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
No symbol table info available.
#22 0x011abd2d in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
No symbol table info available.
#23 0x011aa9fb in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
No symbol table info available.
#24 0x011abd2d in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
No symbol table info available.
#25 0x0111786b in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
No symbol table info available.
#26 0x0111b57a in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
No symbol table info available.
#27 0x01237a02 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
No symbol table info available.
#28 0x0123bd08 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
No symbol table info available.
#29 0x0123bee5 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
No symbol table info available.
#30 0x00de74ed in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
No symbol table info available.
#31 0x01246eaf in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
No symbol table info available.
#32 0x00ec264b in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
No symbol table info available.
#33 0x00de6e0e in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
No symbol table info available.
#34 0x00a94dc6 in g_timeout_dispatch (source=0x9526810, callback=0, 
    user_data=0xb7270000) at gmain.c:3422
No locals.
#35 0x00a947f2 in IA__g_main_context_dispatch (context=0x94d2ba0)
    at gmain.c:2045
No locals.
#36 0x00a977cf in g_main_context_iterate (context=0x94d2ba0, block=1, 
    dispatch=1, self=0x94d5ff0) at gmain.c:2677
        got_ownership = <value optimized out>
        max_priority = 0
        timeout = 0
        some_ready = 1
        nfds = <value optimized out>
        allocated_nfds = <value optimized out>
        fds = (GPollFD *) 0x94d6018
        __PRETTY_FUNCTION__ = "g_main_context_iterate"
#37 0x00a97b79 in IA__g_main_loop_run (loop=0x94d3b10) at gmain.c:2881
        got_ownership = 0
        self = (GThread *) 0x94d5ff0
        __PRETTY_FUNCTION__ = "IA__g_main_loop_run"
#38 0x0231af44 in IA__gtk_main () at gtkmain.c:1154
        tmp_list = (GList *) 0x94d5f20
        functions = (GList *) 0x0
        init = (GtkInitFunction *) 0x94a9050
        loop = (GMainLoop *) 0x94d3b10
#39 0x08050602 in main (argc=<value optimized out>, argv=0xbf9136f4)
    at ../src/npw-viewer.c:3222
        plugin_name = <value optimized out>
        plugin_desc = <value optimized out>
        mime_info = <value optimized out>
        plugin_path = 0xbf9147ba "/usr/lib/mozilla/plugins/libflashplayer.so"
        connection_path = 0xbf9147f2
"/org/wrapper/NSPlugins/libflashplayer.so/31391-1"
        cmd = 0
        handle = (void *) 0x94a9050
        ret = <value optimized out>
#40 0x0055ff70 in __libc_start_main (main=0x804fe80 <main>, argc=5, 
    ubp_av=0xbf9136f4, init=0x805d890 <__libc_csu_init>, 
    fini=0x805d880 <__libc_csu_fini>, rtld_fini=0x5353d0 <_dl_fini>, 
    stack_end=0xbf9136ec) at libc-start.c:222
        result = <value optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {6922228, 5516448, 0, 
        -1081002296, 32839544, -2006475769}, mask_was_saved = 0}}, priv = {
    pad = {0x0, 0x0, 0x53a2c0, 0x55fe9d}, data = {prev = 0x0, cleanup = 0x0, 
      canceltype = 5481152}}}
        not_first_call = <value optimized out>
#41 0x0804a631 in _start ()
No symbol table info available.
(gdb) 


Comment 4 Julian Sikorski 2007-11-01 11:57:50 UTC
Not sure why that one was so much longer. Anyway, here goes the backtrace
obtained from i386 firefox running on my Fedora 8/x86_64 box:

(gdb) bt
#0  IA__g_str_hash (v=0x1) at gstring.c:95
#1  0x001219bb in IA__g_hash_table_lookup (hash_table=0x807f600, key=0x1)
    at ghash.c:236
#2  0x00119dd7 in IA__g_quark_from_string (
    string=0x1 <Address 0x1 out of bounds>) at gdataset.c:625
#3  0x00415364 in g_object_dispatch_properties_changed (object=0x810c810, 
    n_pspecs=6, pspecs=0xffe60988) at gobject.c:563
#4  0x00411d4f in g_object_notify_dispatcher (object=0x810c810, n_pspecs=6, 
    pspecs=0xffe60988) at gobject.c:245
#5  0x0041697e in IA__g_object_newv (object_type=135020136, n_parameters=8, 
    parameters=0x8106db8) at gobjectnotifyqueue.c:123
#6  0x00417038 in IA__g_object_new_valist (object_type=135020136, 
    first_property_name=0x5aff48 "colorspace", var_args=0xffe60b04 "")
    at gobject.c:1027
#7  0x00417140 in IA__g_object_new (object_type=135020136, 
    first_property_name=0x5aff48 "colorspace") at gobject.c:795
#8  0x005a1384 in IA__gdk_pixbuf_new_from_data (data=0x81dc928 "", 
    colorspace=GDK_COLORSPACE_RGB, has_alpha=1, bits_per_sample=8, width=477, 
    height=79, rowstride=1908, destroy_fn=0x59f2a0 <free_buffer>, 
    destroy_fn_data=0x0) at gdk-pixbuf-data.c:65
#9  0x0059f17a in IA__gdk_pixbuf_new (colorspace=GDK_COLORSPACE_RGB, 
    has_alpha=1, bits_per_sample=8, width=477, height=79) at gdk-pixbuf.c:273
#10 0xf7842dfa in g_free () at gmem.c:183
---Type <return> to continue, or q <return> to quit---
#11 0xf7843267 in g_free () at gmem.c:183
#12 0xf780c7e2 in g_free () at gmem.c:183
#13 0xf77f39a0 in g_free () at gmem.c:183
#14 0xf7822620 in g_free () at gmem.c:183
#15 0xf78232d0 in g_free () at gmem.c:183
#16 0xf782362e in g_free () at gmem.c:183
#17 0xf7b321f0 in g_free () at gmem.c:183
#18 0xf7b319fb in g_free () at gmem.c:183
#19 0xf7b32d2d in g_free () at gmem.c:183
#20 0xf7b319fb in g_free () at gmem.c:183
#21 0xf7b32d2d in g_free () at gmem.c:183
#22 0xf7b319fb in g_free () at gmem.c:183
#23 0xf7b32d2d in g_free () at gmem.c:183
#24 0xf7a9e86b in g_free () at gmem.c:183
#25 0xf7aa257a in g_free () at gmem.c:183
#26 0xf7bbea02 in g_free () at gmem.c:183
#27 0xf7bc2d08 in g_free () at gmem.c:183
#28 0xf7bc2ee5 in g_free () at gmem.c:183
#29 0xf776e4ed in g_free () at gmem.c:183
#30 0xf7bcdeaf in g_free () at gmem.c:183
#31 0xf784964b in g_free () at gmem.c:183
#32 0xf776de0e in g_free () at gmem.c:183
#33 0x0012e8c6 in g_timeout_dispatch (source=0x810c788, callback=0x1, 
---Type <return> to continue, or q <return> to quit---
    user_data=0xf6842000) at gmain.c:3488
#34 0x0012e10c in IA__g_main_context_dispatch (context=0x80acb20)
    at gmain.c:2061
#35 0x0013154f in g_main_context_iterate (context=0x80acb20, block=1, 
    dispatch=1, self=0x808a540) at gmain.c:2694
#36 0x001318f9 in IA__g_main_loop_run (loop=0x80acff0) at gmain.c:2898
#37 0x03038ae4 in IA__gtk_main () at gtkmain.c:1146
#38 0x08050342 in main (argc=<value optimized out>, argv=0xffe628e4)
    at ../src/npw-viewer.c:3222
#39 0x00c12390 in __libc_start_main (main=0x804fbf0 <main>, argc=5, 
    ubp_av=0xffe628e4, init=0x805d900 <__libc_csu_init>, 
    fini=0x805d8f0 <__libc_csu_fini>, rtld_fini=0xbeb940 <_dl_fini>, 
    stack_end=0xffe628dc) at libc-start.c:220
#40 0x0804a6e1 in _start ()
(gdb) 

Comment 5 Julian Sikorski 2007-11-02 09:27:10 UTC
Another crasher:
http://rezydencja.org

Comment 6 Julian Sikorski 2007-11-06 16:52:23 UTC
Hmm, any updates on this? I tried contacting upstream about that, but got no
response. Martin, maybe you could try?
The fact that crash occurs for i386 as well, combined with wrapping native
plugins by default, could cause a lot of pain for users coming from Fedora 7.

Comment 7 Mike A. Harris 2007-11-12 15:42:24 UTC
I'm not running rawhide, just stock F8+ updates on x86_64, but I saw this bug
and thought I'd add this as a datapoint in case it is useful.

These 3 pages work fine for me on F8/x86_64 with nspluginwrapper using 64bit
firefox:

http://www.speedtest.net
http://www.enemyterritory.com
http://www.playmobile.pl

The http://rezydencja.org URL from comment #5 brings up a static page.  Flash
still seems to work fine for other stuff also.

firefox-2.0.0.8-2.fc8
firefox-2.0.0.8-2.fc8
flash-plugin-9.0.48.0-release
nspluginwrapper-0.9.91.5-12.fc8
nspluginwrapper-0.9.91.5-12.fc8

Dunno if any of this information is useful, but here it is nonetheless. ;o)


Comment 8 Julian Sikorski 2007-11-12 15:49:02 UTC
Yeah, http://rezydencja.org brings a static page. Flash has been there before.

Comment 9 Julian Sikorski 2007-11-12 15:59:19 UTC
I can confirm that 9.0.48 version of Flash works fine with these sites. The
issue is only present with 9.0.64 release candidate, available from
http://labs.adobe.com.

Comment 10 cac 2007-11-29 04:15:10 UTC
I was having this issue, bug buddy indicated:

  Could not open library '/usr/lib/kde3/knotify.la'.

Installing libkde4 resolved the problem for me

Comment 11 Warren Togami 2007-11-29 05:09:35 UTC
cac.wa.us, what you are describing sounds like it has nothing to do
with this bug?


Comment 12 Julian Sikorski 2007-12-03 06:50:42 UTC
What's bug #221356? Getting Access Denied here. Was some RHEL customer hit by this?

Comment 13 Warren Togami 2007-12-03 16:28:34 UTC
Basically yes.

And hmm... Adobe's upcoming 9.0.115 release also crashes when wrapped. =(

Comment 14 Matt Thompson 2007-12-04 14:22:38 UTC
I am not getting crashes with my Firefox + wrapper setup with 9.0.115.  Rather,
I see gray boxes on all those sites.  In fact, I also get this effect with
http://sportsillustrated.cnn.com/ .  When that site is reloaded, you can just
see the Flash load, and then, bam, gray boxes.  Info:

firefox-2.0.0.10-2.fc8.x86_64
nspluginwrapper-0.9.91.5-12.fc8.x86_64
nspluginwrapper-0.9.91.5-12.fc8.i386
flash-plugin-9.0.115.0-release.i386

I'll provide any other details if needed, but nspluginwrapper, xembed, etc.
makes my eyes water...

Comment 15 Julian Sikorski 2007-12-04 14:30:04 UTC
What you are seeing is the crash. The wrapper crash, not the browser crash.

Comment 16 Warren Togami 2007-12-04 14:30:51 UTC
You don't see BROWSER crashes because nspluginwrapper is running the plugins in
a separate process called npviewer.bin which definitely is crashing.

dmesg:
npviewer.bin[3532]: segfault at 0000000073776f72 rip 00000000009ab79f rsp
00000000f6532c50 error 4


Comment 17 Warren Togami 2007-12-08 05:15:36 UTC
https://bugs.launchpad.net/ubuntu/+source/nspluginwrapper/+bug/141613
Ubuntu's equivalent to this bug.

Comment 18 Martin Stransky 2007-12-10 11:38:03 UTC
*** Bug 417641 has been marked as a duplicate of this bug. ***

Comment 19 Warren Togami 2007-12-11 02:39:58 UTC
firefox-2.0.0.10-2.fc8
nspluginwrapper-0.9.91.5-13.fc8
flash-plugin-9.0.115.0-release

ulimit -c unlimited; firefox
http://www.adobe.com/products/creativesuite/productselector/
Wait a few seconds for the plugin to crash.
gdb /usr/lib/nspluginwrapper/npviewer.bin core.XXXX

(gdb) bt
#0  IA__g_slice_alloc (mem_size=8) at gslice.c:474
#1  0x0058b8a2 in IA__g_slist_prepend (list=0x0, data=0x80ada30) at gslist.c:91
#2  0x003723bc in g_object_constructor (type=134927048,
n_construct_properties=8, construct_params=0xf401df30) at gobjectnotifyqueue.c:154
#3  0x003703eb in IA__g_object_newv (object_type=134927048, n_parameters=8,
parameters=0xf401dd58) at gobject.c:937
#4  0x00371038 in IA__g_object_new_valist (object_type=134927048,
first_property_name=0x3c8f48 "colorspace", var_args=0xf6532fb4 "") at gobject.c:1027
#5  0x00371140 in IA__g_object_new (object_type=134927048,
first_property_name=0x3c8f48 "colorspace") at gobject.c:795
#6  0x003ba384 in IA__gdk_pixbuf_new_from_data (data=0xf4000468 "",
colorspace=GDK_COLORSPACE_RGB, has_alpha=1, bits_per_sample=8, width=531,
height=57, rowstride=2124, 
    destroy_fn=0x3b82a0 <free_buffer>, destroy_fn_data=0x0) at gdk-pixbuf-data.c:65
#7  0x003b817a in IA__gdk_pixbuf_new (colorspace=GDK_COLORSPACE_RGB,
has_alpha=1, bits_per_sample=8, width=531, height=57) at gdk-pixbuf.c:273
#8  0xf7843cf0 in g_free () at gmem.c:183
#9  0xf7844187 in g_free () at gmem.c:183
#10 0xf780d702 in g_free () at gmem.c:183
#11 0xf7967d35 in g_free () at gmem.c:183
#12 0xf786ea7d in g_free () at gmem.c:183
#13 0x0043450b in start_thread () from /lib/libpthread.so.0
#14 0x002aab2e in clone () from /lib/libc.so.6

Comment 20 Warren Togami 2007-12-11 03:04:24 UTC
G_SLICE=always-malloc firefox

This works around the above backtrace and allows more Flash files to work
without crashing, like the above example.

http://library.gnome.org/devel/glib/unstable/glib-running.html
"This will cause all slices allocated through g_slice_alloc() and released by
g_slice_free1() to be actually allocated via direct calls to g_malloc() and
g_free()."  (Adobe: Read this page for some debugging tips, you might avoid
future bugs like this.)

Possible explanations:
1) g_free() worked in prior versions of glib2, but it was being used improperly
when an object-type specific free() method should have been used instead.  This
poor assumption was actually a bug, and led to breakage with changes to upstream
glib2 that were supposed to be private and not exposed to applications.
2) Other memory corruption somewhere else (either in Flash Player or far less
likely, nspluginwrapper.)
3) (Very Unlikely) glib2 ABI broke without anybody noticing through F7 and F8.

Unfortunately, it still crashes readily on other Flash files like:
http://www.enemyterritory.com/
Try the above method of running firefox, and watch the movie here for a short
while.  It will eventually crash.

(gdb) bt
#0  0x00370476 in IA__g_object_newv (object_type=134905128, n_parameters=8,
parameters=0xf2672368) at gobject.c:808
#1  0x00371038 in IA__g_object_new_valist (object_type=134905128,
first_property_name=0x3c8f48 "colorspace", var_args=0xfff334c4 "") at gobject.c:1027
#2  0x00371140 in IA__g_object_new (object_type=134905128,
first_property_name=0x3c8f48 "colorspace") at gobject.c:795
#3  0x003ba384 in IA__gdk_pixbuf_new_from_data (data=0xf229ba48 "",
colorspace=GDK_COLORSPACE_RGB, has_alpha=1, bits_per_sample=8, width=691,
height=47, rowstride=2764, 
    destroy_fn=0x3b82a0 <free_buffer>, destroy_fn_data=0x0) at gdk-pixbuf-data.c:65
#4  0x003b817a in IA__gdk_pixbuf_new (colorspace=GDK_COLORSPACE_RGB,
has_alpha=1, bits_per_sample=8, width=691, height=47) at gdk-pixbuf.c:273
#5  0xf7843d1a in g_free () at gmem.c:183
#6  0xf7844187 in g_free () at gmem.c:183
#7  0xf780d702 in g_free () at gmem.c:183
#8  0xf77f5b0c in g_free () at gmem.c:183
#9  0xf7823540 in g_free () at gmem.c:183
#10 0xf78241f0 in g_free () at gmem.c:183
#11 0xf782454e in g_free () at gmem.c:183
#12 0xf7b34550 in g_free () at gmem.c:183
#13 0xf7b33d5b in g_free () at gmem.c:183
#14 0xf7b3508d in g_free () at gmem.c:183
#15 0xf7b33d5b in g_free () at gmem.c:183
#16 0xf7b3508d in g_free () at gmem.c:183
#17 0xf7b33d5b in g_free () at gmem.c:183
#18 0xf7b3508d in g_free () at gmem.c:183
#19 0xf7b33d5b in g_free () at gmem.c:183
#20 0xf7b3508d in g_free () at gmem.c:183
#21 0xf7b33d5b in g_free () at gmem.c:183
#22 0xf7b3508d in g_free () at gmem.c:183
#23 0xf7aa0c5d in g_free () at gmem.c:183
#24 0xf7aa488a in g_free () at gmem.c:183
#25 0xf7bc1162 in g_free () at gmem.c:183
#26 0xf7bc5738 in g_free () at gmem.c:183
#27 0xf7bc5915 in g_free () at gmem.c:183
#28 0xf776e55d in g_free () at gmem.c:183
#29 0xf7bd08df in g_free () at gmem.c:183
#30 0xf784a63b in g_free () at gmem.c:183
#31 0xf776e01e in g_free () at gmem.c:183
#32 0x0056e8c6 in g_timeout_dispatch (source=0x80c5b98, callback=0x89,
user_data=0xf6741000) at gmain.c:3488
#33 0x0056e10c in IA__g_main_context_dispatch (context=0x8094650) at gmain.c:2061
#34 0x0057154f in g_main_context_iterate (context=0x8094650, block=1,
dispatch=1, self=0x8087860) at gmain.c:2694
#35 0x005718f9 in IA__g_main_loop_run (loop=0x8096db0) at gmain.c:2898
#36 0x03d82ae4 in IA__gtk_main () at gtkmain.c:1146
#37 0x08050342 in main (argc=<value optimized out>, argv=0xfff35974) at
../src/npw-viewer.c:3222
#38 0x001ed390 in __libc_start_main () from /lib/libc.so.6
#39 0x0804a6e1 in _start ()

Comment 21 Warren Togami 2007-12-11 03:13:55 UTC
I'm unable to reproduce these crashes on-demand in unwrapped i386 firefox,
making the "glib2 changed" explanation less likely.  It remains unclear if Flash
Player or nspluginwrapper is to blame here. 

Comment 22 Warren Togami 2007-12-11 04:23:12 UTC
G_SLICE=always-malloc _MALLOC_PERTURB=0
Running npviewer.bin with both of these environment variables crashes a LOT
sooner and more often than G_SLICE=always-malloc alone.  _MALLOC_PERTURB=0 sets
the entire g_malloc() to zero's instead of leaving the memory uninitialized. 
The backtrace of an instant crash when visiting http://www.enemyterritory.com/
is almost identical to Comment #19.

By the fact that behavior changes when _MALLOC_PERTURB=0 is used, and the length
of time to crash with G_SLICE=always-malloc is variable, this points more toward
memory corruption somewhere.  But we still have no idea what is causing it.

Comment 23 Warren Togami 2007-12-11 04:47:22 UTC
http://developer.mozilla.org/en/docs/XEmbed_Extension_for_Mozilla_Plugins
A key difference in flash-plugin-9.0.115.0 from 9.0.48.0 is switching to XEmbed.
 I found this description of the differences this entails by searching Google.

https://bugzilla.redhat.com/show_bug.cgi?id=410651
http://bugs.kde.org/132138
http://bugs.kde.org/146784
Apparently KDE's konqueror was hit hard by this, because konqueror lacks XEmbed
support entirely.  nspluginwrapper has XEmbed code... but it is unknown how
complete or correct it is.  It is possible that nspluginwrapper's implementation
needs work?

Did any plugins before Flash actually use XEmbed? (hence nspluginwrapper's
XEmbed implementation might be relatively untested)

Comment 24 Julian Sikorski 2007-12-11 12:00:16 UTC
Did anybody try to pursue Adobe with this? They have access to Flash source
code, so they probably could determine the culprit more easily.

Comment 25 Warren Togami 2007-12-12 17:59:49 UTC
I'm unable to reproduce the above mentioned crashes like enemyterritory.com on
F8 i386 with nspluginwrapper.  However, F8 x86_64 running "setarch i386 firefox"
crashes with identical backtraces to this report.

NO CRASH: Unwrapped on F8 i386
NO CRASH: 32_32 wrapped on F8 i386
CRASH: 32_64 wrapped on F8 x86_64
CRASH: 32_32 wrapped on F8 x86_64

Huh?

Comment 26 Martin Stransky 2007-12-12 20:21:01 UTC
(In reply to comment #23)
> support entirely.  nspluginwrapper has XEmbed code... but it is unknown how
> complete or correct it is.  It is possible that nspluginwrapper's implementation
> needs work?
> 
> Did any plugins before Flash actually use XEmbed? (hence nspluginwrapper's
> XEmbed implementation might be relatively untested)

XEmbed is used in mplayerplug-in too and it works w/o any crash (at least i
don't see any issue on my box). But the XEmbed code can be incomplete/untested
so I'll check what's going on here.

Comment 27 drago01 2007-12-12 20:30:41 UTC
I can confirm this crashes on my box too (laptop too) .. both using fc8 x86_64
and  9.0.115 (9.0.64 was crashing too)

Comment 28 Warren Togami 2007-12-12 20:34:08 UTC
> NO CRASH: Unwrapped on F8 i386
> NO CRASH: 32_32 wrapped on F8 i386
> CRASH: 32_64 wrapped on F8 x86_64
> CRASH: 32_32 wrapped on F8 x86_64

I think these test results are telling of *something* important.  32_32 wrapped
on F8 i386 for me is behaving exactly like i386 unwrapped.  But that should
theoretically be exactly the same as 32_32 wrapped on i386 Firefox running on
x86_64.  Why isn't it?

Comment 29 Julian Sikorski 2007-12-12 20:54:50 UTC
Mplayerplug-in never crashed for me either.

Comment 30 Julian Sikorski 2007-12-13 12:29:31 UTC
F8/i386 wrapped does crash for me:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1227555952 (LWP 4753)]
magazine_cache_push_magazine (ix=1, magazine_chunks=0xb330df50, count=51)
    at gslice.c:470
470       ChunkLink *chunk = (*magazine_chunks)->data;
(gdb) bt
#0  magazine_cache_push_magazine (ix=1, magazine_chunks=0xb330df50, count=51)
    at gslice.c:470
#1  0x00466455 in thread_memory_magazine2_unload (tmem=<value optimized out>, 
    ix=0) at gslice.c:744
#2  0x00467348 in IA__g_slice_free1 (mem_size=12, mem_block=0xb330df20)
    at gslice.c:868
#3  0x00449369 in IA__g_list_free_1 (list=0xb330df20) at glist.c:59
#4  0x009db3b4 in IA__g_object_newv (object_type=163696168, n_parameters=8, 
    parameters=0xb330dc70) at gobject.c:932
#5  0x009dc038 in IA__g_object_new_valist (object_type=163696168, 
    first_property_name=0xd10f48 "colorspace", var_args=0xb6d4efb4 "")
    at gobject.c:1027
#6  0x009dc140 in IA__g_object_new (object_type=163696168, 
    first_property_name=0xd10f48 "colorspace") at gobject.c:795
#7  0x00d02384 in IA__gdk_pixbuf_new_from_data (
    data=0xb3300468 "\020\0040�\020\0040�`\0040�`\0040�", 
    colorspace=GDK_COLORSPACE_RGB, has_alpha=1, bits_per_sample=8, width=288, 
    height=48, rowstride=1152, destroy_fn=0xd002a0 <free_buffer>, 
    destroy_fn_data=0x0) at gdk-pixbuf-data.c:65
#8  0x00d0017a in IA__gdk_pixbuf_new (colorspace=GDK_COLORSPACE_RGB, 
    has_alpha=1, bits_per_sample=8, width=288, height=48) at gdk-pixbuf.c:273
#9  0x00ee7cf0 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
#10 0x00ee8187 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
---Type <return> to continue, or q <return> to quit---
#11 0x00eb1702 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
#12 0x0100bd35 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
#13 0x00f12a7d in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so
#14 0x00cc950b in start_thread () from /lib/libpthread.so.0
#15 0x00c0ab2e in clone () from /lib/libc.so.6
(gdb)

Comment 31 Warren Togami 2007-12-13 16:10:06 UTC
I was wrong about _MALLOC_PERTURB=0.  It actually sets all malloc'ed memory to
255 when allocated, and 0 when freed.  The fact that the G_SLICE workaround
makes it survive a bit longer and _MALLOC_PERTURB=0 makes it crash sooner points
to memory corruption.

Some RHEL5 i386 unwrapped users have reported several crashes daily after they
upgraded from flash-plugin-9.0.48.0 to flash-plugin-9.0.115.0.  It is too early
to know for sure, but reportedly G_SLICE=always-malloc is helping to have fewer
crashes on RHEL5 i386 unwrapped.  This also points to memory corruption going on
within the Flash plugin itself.

With the G_SLICE workaround and running npviewer.bin in valgrind, you see:
Conditional jump or move depends on uninitialised value(s)
Use of uninitialised value of size 4

Since libflashplayer.so is missing symbols we cannot know where these are
happening.  Adobe should run a debug build in valgrind themselves.

Comment 32 Julian Sikorski 2007-12-13 17:07:53 UTC
Are you going to chase them to do that?

Comment 33 Warren Togami 2007-12-13 22:55:04 UTC
I am unable to make flash-plugin-9.0.115.0 crash on-demand on F8 i386 wrapped in
both a KVM guest and the Thinkpad T41.  Yet comment #30 indicates that F8 i386
wrapped can indeed crash in exactly the same way as x86_64 wrapped.

This makes me wonder if there is some codepath difference in the presence of
certain hardware features (processor type, X, DRI or something else) because of
9.0.115.0's new GL rendering.  It isn't crashing for me at all on two slower
systems that struggle to animate the crashing test cases.

What kind of hardware (processor, chipset, video etc.) are you running Julian?

Comment 34 Julian Sikorski 2007-12-14 00:16:45 UTC
The i386 box is a desktop equipped with P4 3.0E CPU, ICH5 chipset, GeForce
fx5700 GPU (nvidia driver).

Comment 35 Mike A. Harris 2007-12-14 02:39:30 UTC
(In reply to comment #7)
> I'm not running rawhide, just stock F8+ updates on x86_64, but I saw this bug
> and thought I'd add this as a datapoint in case it is useful.
> 
> These 3 pages work fine for me on F8/x86_64 with nspluginwrapper using 64bit
> firefox:
> 
> http://www.speedtest.net
> http://www.enemyterritory.com
> http://www.playmobile.pl
> 
> The http://rezydencja.org URL from comment #5 brings up a static page.  Flash
> still seems to work fine for other stuff also.
> 
> firefox-2.0.0.8-2.fc8
> firefox-2.0.0.8-2.fc8
> flash-plugin-9.0.48.0-release
> nspluginwrapper-0.9.91.5-12.fc8
> nspluginwrapper-0.9.91.5-12.fc8
> 
> Dunno if any of this information is useful, but here it is nonetheless. ;o)

Just an additional datapoint - I've updated to the new flash-plugin 9.0.115.0
release, here's my current package versions:

rpm -q firefox flash-plugin nspluginwrapper
firefox-2.0.0.10-2.fc8
firefox-2.0.0.10-2.fc8
flash-plugin-9.0.115.0-release
nspluginwrapper-0.9.91.5-12.fc8
nspluginwrapper-0.9.91.5-12.fc8

All of the flash sites referenced above are working fine for me in
Fedora 8/x86_64 still.  No crashes have occured yet.


Comment 36 Warren Togami 2007-12-14 03:11:30 UTC
I am beginning to think that instant/rapid crash while wrapped depends on a
certain codepath taken by a certain hardware feature.  We need to compare
hardware and crash/no crash to figure out what it could be.


Comment 37 Brent R Brian 2007-12-14 12:16:02 UTC
Just another data point for you, I have this failing on:

  * DELL Inspiron 1420 laptop, dual celeron, F8
  * IBM Thinkpad 600e (400mhz PII), F8

All the rest of my machines are FC1, FC6 and FC7 with no problems.  All are
running on native hardware, no VM's and all are current on their updates.

Comment 38 Julian Sikorski 2007-12-14 12:37:47 UTC
OK then. My F8/x86_64 box is a Toshiba Satellite A100-847. It has Core 2 Duo
T7200 CPU, GeForce Go 7600 GPU and ICH7 chipset. Also running nvidia binary driver.
According to what Adobe say, hardware video acceleration is only used if SFW
specifies it.

Comment 39 Warren Togami 2007-12-14 17:31:10 UTC
Created attachment 289281 [details]
valgrind --tool=memcheck --leak-check=no --freelist-vol=100000000 --log-file=/tmp/flash $NPW_VIEWER_DIR/npviewer.bin ${1+"$@"}

valgrind log of npviewer.bin wrapping flash-plugin-9.0.115.0 while it attempts
to load enemyterritory.com.  You see various:
* Conditional jump or move depends on uninitialised value(s)
* Use of uninitialised value of size 4

It is unclear if these are related to the crashes we are seeing.  Adobe should
run this test themselves with a Flash binary with debugging symbols.

Comment 40 Eelco Hoekema 2007-12-15 20:19:22 UTC
Created attachment 289705 [details]
Bug buddy bug report

I'm running F8 i386 on a Macbook Intel core 2 duo. I'm not sure what 'wrapped'
or 'unwrapped' means, but i have these installed:

nspluginwrapper-0.9.91.5-12.fc8
flash-plugin-9.0.115.0-release
libflashsupport-000-0.1.svn20070904

kernel.i686 2.6.23.8-63.fc8

Comment 41 Warren Togami 2007-12-17 19:18:37 UTC
RHEL5 i386 user running with Firefox and NO nspluginwrapper
===========================================================
- G_SLICE=always-malloc
This option alone brought his browser crashes from ~3/day to zero. 
Unfortunately he only manages to crash 9.0.115.0 with 2-3 dozen browser windows
open.  Visiting individual sites does not seem to crash it, so an quick
reproduce procedure is not easy to obtain.
- G_SLICE=always-malloc _MALLOC_PERTURB=0
This option seemed to undo the effect of G_SLICE=always-malloc alone, bringing
back the occasional crashes in Flash 9.0.115.0.  This is further indicative of
memory corruption going on within the plugin.

Comment 42 Warren Togami 2007-12-18 06:55:38 UTC
Eureka!

Intel Centrino laptop i386, single core:
Flash has very few crashes, wrapped or unwrapped.
Intel Core 2 Duo laptop i386, dual core:
Flash crashes readily when wrapped, crashes far less often unwrapped.

What is the difference here?  Uni-Processor vs. SMP

Workaround #1: Fool /proc/cpuinfo with mount --bind
===================================================
Flash plugin has "/proc/cpuinfo" within its strings so it is likely that it
reads it.  I copied /proc/cpuinfo from the single core laptop to a text file on
the dual core laptop.  I then used "mount --bind" so if you read /proc/cpuinfo
you read the cpuinfo of the single-core laptop.  Flash seems to last *MUCH*
longer before crashing when it read the older Centrino's single processor
/proc/cpuinfo.  I then tried the dual core's /proc/cpuinfo, but this time edited
to remove one of the two cores.  This seemed to make it far more stable as well.

OK, I don't actually know if Flash itself or glibc/some other library is
modifying the behavior based upon how many processors it sees in /proc/cpuinfo,
but the behavior does seem to change.

It seems to be very stable when it thinks it has only one core, but it *does*
crash sometimes.  It is possible that a race condition could trigger (although
more rarely) on uni-processor due to unpredictable scheduler behavior, like if a
thread is migrated from one core to another.

Workaround #2: Force CPU Affinity of Wrapped Flash Plugin
=========================================================
1) yum install schedutils
2) Edit /usr/lib/nspluginwrapper/npviewer
3) Change the last line of the script:
- exec $LOADER $NPW_VIEWER_DIR/npviewer.bin ${1+"$@"}
+ exec taskset -c 0 $LOADER $NPW_VIEWER_DIR/npviewer.bin ${1+"$@"}
4) Run browser, load http://www.enemyterritory.com/
5) Doesn't crash easily (at all?  Too early to tell.)

Theory
======
SMP + wrapper could be readily crashing because it is exposing an otherwise rare
race condition.  The wrapper makes possible for Flash and (blocking? timing
dependent?) graphical output to be running in a separate processes.  Perhaps
this part of the traceback is the result of a race condition?

#4  0x003b817a in IA__gdk_pixbuf_new (colorspace=GDK_COLORSPACE_RGB,
has_alpha=1, bits_per_sample=8, width=691, height=47) at gdk-pixbuf.c:273
#5  0xf7843d1a in g_free () at gmem.c:183

Single processor or forced CPU affinity locks all Flash threads onto a single
processor, sequential operation.  Without affinity, if you have multiple
processors threads could possibly migrate onto other cores.  The kernel
scheduler migrating threads in SMP could possibly explain why we do not see the
race condition in uni-processor or affinity locked operation.  Scheduler
migration of threads is difficult to predict, and could possibly explain why we
see Flash crashing at unpredictable and seemingly random times earlier in this
report.

Is this race condition within Adobe's Flash Player 9.0.115.0 itself?  Almost
certainly yes.

Can other people here confirm this uni-processor vs. SMP (including
hyperthreading) behavior?

Comment 43 Warren Togami 2007-12-18 07:37:11 UTC
http://koji.fedoraproject.org/packages/nspluginwrapper/0.9.91.5/13.fc8/
Everyone on F8, please test this build of nspluginwrapper with the above
workaround.  It uses the below to randomly select a processor instead of being
hard-coded to a certain processor.

CPU=$[$RANDOM % `getconf _NPROCESSORS_ONLN`]
exec taskset -c $CPU $LOADER $NPW_VIEWER_DIR/npviewer.bin ${1+"$@"}

Comment 44 drago01 2007-12-18 07:46:47 UTC
good catch Warren ;) .. seems to be it.
nspluginwrapper-0.9.91.5-14 seems to work fine for me.
Someone has to report it to Adobe...

Comment 45 Warren Togami 2007-12-18 07:58:33 UTC
Oops, wrong URL:
http://koji.fedoraproject.org/packages/nspluginwrapper/0.9.91.5/14.fc8/

Comment 46 Martin Stransky 2007-12-18 11:05:24 UTC
*** Bug 425984 has been marked as a duplicate of this bug. ***

Comment 47 The Source 2007-12-18 11:15:02 UTC
crash on this URL
http://www.gimme5games.com/index.jsp?id=pm_red

I have latest version of wrapper nspluginwrapper-0.9.91.5-13.fc8 and flash
player still crashes (9.0.r115).

Comment 48 Martin Stransky 2007-12-18 11:25:44 UTC
you need to install this one:
http://koji.fedoraproject.org/packages/nspluginwrapper/0.9.91.5/14.fc8/

Comment 49 Matt Thompson 2007-12-18 12:08:42 UTC
(In reply to comment #43)

From limited testing on my Xeon quad-core, 0.9.91.5-14 does seem to fix the
problem.  And that Enemy Territory site does a bang-up job of pegging a single
core.  (For my own education, will that SMP workaround put all Flash on the same
processor/core if you have multiple sites open in tabs at once?)

Comment 50 Torsten Rausche 2007-12-18 12:19:56 UTC
(In reply to comment #43)
> Everyone on F8, please test this build of nspluginwrapper with the above
> workaround.  It uses the below to randomly select a processor instead of being
> hard-coded to a certain processor.

nspluginwrapper-0.9.91.5-14.fc8 seems to work around the problem indeed. I
couldn't reproduce the crashes with the new version.

The system is an up to date F8 x86_64 on an Athlon64 X2.

Used package versions:
nspluginwrapper-0.9.91.5-14.fc8.i386
nspluginwrapper-0.9.91.5-14.fc8.x86_64
firefox-2.0.0.10-3.fc8.x86_64
flash-plugin-9.0.115.0-release.i386
kernel-2.6.23.8-63.fc8.x86_64
glibc-2.7-2.i386
glibc-2.7-2.x86_64


Comment 51 Brent R Brian 2007-12-18 12:23:05 UTC
This does not sound like a fix for single CPU systems, is it ?

Comment 52 The Source 2007-12-18 12:56:26 UTC
I noticed that mozilla-plugin-config does not quit after all plugins are
wrapped. It remains in system and eats a lot of CPU time. I had to terminate the
process.

Comment 53 Martin Stransky 2007-12-18 13:03:35 UTC
(In reply to comment #52)
> I noticed that mozilla-plugin-config does not quit after all plugins are
> wrapped. It remains in system and eats a lot of CPU time. I had to terminate the
> process.

Please file a new bug for it.

Comment 54 The Source 2007-12-18 13:10:36 UTC
I'm sorry but the bug is not fixed. Even with version linked above the following
flash crashes frequently
http://members.home.nl/motas/editor/engine.htm?myl=1&u=logan&g=demo

Comment 55 Warren Togami 2007-12-18 14:07:12 UTC
I noticed that there are *other* crashes other than this SMP race condition, like:

https://bugzilla.redhat.com/show_bug.cgi?id=421981
Pulseaudio crash

And another pulseaudio ALSA crash that I haven't managed to get a traceback yet.

Comment 56 drago01 2007-12-18 14:42:53 UTC
so tested on an other box (amd opteron 170 (dualcore); F8 x86_64) 
nspluginwrapper-0.9.91.5-14.fc8 seems to work here too. (other box as was core 2
duo based laptop running F8 x86_64)

Comment 57 Julian Sikorski 2007-12-18 15:35:35 UTC
I can confirm that all crashes I was encountering are gone with
nspluginwrapper-0.9.91.5-14.fc8.

Comment 58 Fedora Update System 2007-12-20 19:49:36 UTC
nspluginwrapper-0.9.91.5-14.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 59 Brent R Brian 2007-12-21 02:16:53 UTC
Does not help single processor PII 400Mhz IBM 600 Thinkpad i386

Comment 60 Warren Togami 2007-12-21 02:33:35 UTC
Please follow the instructions in Comment #19 to get a core file then obtain a
backtrace.  Please attach that backtrace (DO NOT PASTE).

Comment 61 The Source 2007-12-21 05:58:15 UTC
Like I said fix does not work for
http://members.home.nl/motas/editor/engine.htm?myl=1&u=logan&g=demo

Perhaps the problem is not in smp race there. This flash uses MIDI and the
problem might be there. As for pulse audio - I removed alsa-plugin-pulseaudio
long ago (it created many problems).

Comment 62 Warren Togami 2007-12-21 06:15:24 UTC
"fix does not work" is not quite true, because this fix was for a specific issue
that is likely not what you are seeing elsewhere.  Continuing to complain about
it here without providing a backtrace is unproductive.

Comment 63 The Source 2007-12-21 06:30:33 UTC
How do I make a backtrace? Should I use strace with firefox?

Comment 64 Julian Sikorski 2007-12-21 09:51:02 UTC
(In reply to comment #63)
> How do I make a backtrace? Should I use strace with firefox?

No. You should:
1. Start firefox
2. Open the site
3. Check the PID of npviewer.bin
4. gdb -p the PID
5. Make the wrapper crash

Comment 65 The Source 2007-12-21 13:42:42 UTC
I have installed debuginfo package for nspluginwrapper but I have a feeling that
gdb misses something. Well, here's what I've got (attached)

Comment 66 The Source 2007-12-21 13:43:28 UTC
Created attachment 290235 [details]
npviewer backtrace

Comment 67 Warren Togami 2007-12-21 16:39:47 UTC
No, attaching gdb to npviewer.bin is insufficient to get a backtrace here. 
Follow the directions in Comment #19.

Hmm, SIGTERM is definitely a different bug.  Please follow the directions in
Comment #19 to get a backtrace and post it to a new bug.

Comment 68 Brent R Brian 2007-12-22 13:49:09 UTC
OK, last round of F8 updates got the thing WORKING again, but it is SLOW - SLOW
- SLOW, about every 20th frame renders and it is SLOW SLOW SLOW



Comment 69 Warren Togami 2007-12-24 19:40:28 UTC
That is unfortunate, that even a single CPU isn't fast enough to render Flash
content at full speed.

I am in contact with upstream nspluginwrapper and Adobe about this issue.  Will
let you folks know if we find a better workaround or if Adobe fixes something.

Comment 70 Julian Sikorski 2007-12-24 19:48:00 UTC
Yeah, the windows player is so much faster. I remember there were some issues
with SIMD instructions a while ago [1], maybe Adobe decided to drop them
altogether? Also, it sometimes seems to me that 9.0.48 was faster, but that can
be a bias due to the fact that it was not supporting fullscreen.

[1] http://www.kaourantin.net/2006/09/gcc-challenges.html

Comment 71 Warren Togami 2007-12-25 04:06:48 UTC
http://koji.fedoraproject.org/scratch/wtogami/task_309550/
Please test this newer build of nspluginwrapper that might fix this issue
without restricting npviewer.bin to a single processor.  Please test it a while
on many sites and report back.

Comment 72 drago01 2007-12-25 10:47:26 UTC
(In reply to comment #71)
> http://koji.fedoraproject.org/scratch/wtogami/task_309550/
> Please test this newer build of nspluginwrapper that might fix this issue
> without restricting npviewer.bin to a single processor.  Please test it a while
> on many sites and report back.

this works fine here.

Comment 73 Julian Sikorski 2007-12-25 10:51:18 UTC
0.9.91.5-15.fc8 seems to work correctly here. No crashes.

Comment 74 The Source 2007-12-25 11:01:53 UTC
I'm sorry, I don't understand how to make backtrace. I did everything like in
comment 19 but gdb just said "no stack" and "core.XXXX no such file or
directory". I only used different flash since the one in comment 19 works fine.

Comment 75 Warren Togami 2007-12-25 18:35:18 UTC
http://koji.fedoraproject.org/packages/nspluginwrapper/0.9.91.5/15.fc8/
Please test this build.  This is *supposed* to be identical to the above scratch
build, but for some reason it fails in a new way for me.  I'm not sure what's
going on.

Comment 76 Julian Sikorski 2007-12-25 18:41:55 UTC
This one seems to work fine as well.

Comment 77 drago01 2007-12-25 20:04:31 UTC
(In reply to comment #75)
> http://koji.fedoraproject.org/packages/nspluginwrapper/0.9.91.5/15.fc8/
> Please test this build.  This is *supposed* to be identical to the above scratch
> build, but for some reason it fails in a new way for me.  I'm not sure what's
> going on.

works fine here too.

Comment 78 Warren Togami 2007-12-26 00:03:23 UTC
OK that was weird.  I used rpm -Uvh --force to upgrade from the scratch build of
15.fc8 from the official 15.fc8 build.  Subsequently the plugin would crash
rapidly after loading enemyterritory.com.  I completely removed nspluginwrapper*
and reinstalled both archs of the official 15.fc8 and it now works.

Pushing to F8 updates testing.

Comment 79 Fedora Update System 2007-12-28 17:15:53 UTC
nspluginwrapper-0.9.91.5-15.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update nspluginwrapper'

Comment 80 Fedora Update System 2008-01-07 01:27:20 UTC
nspluginwrapper-0.9.91.5-15.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 81 Generic User 2008-01-25 02:04:54 UTC
Created attachment 292901 [details]
Bug Buddy's generated npviewer.bin bug report

Comment 82 Generic User 2008-01-25 02:06:22 UTC
While browsing Yahoo! news videos, npviewer.bin causes the firefox browser to
crash.  Bug buddy reports that npviewer.bin has crashed and yields a bug report
that I have saved and have attached; however, it is most puzzling since it seems
to refer to the evolution-data-server in the bug report.

This report is just my initial report of this problem.  I searched bugzilla
first and found this bug, #360891, to have the highest likelihood of having
pertinent information for my problem.  Here are some salient notes:

# uname -a
Linux localhost.localdomain 2.6.23.9-85.fc8 #1 SMP Fri Dec 7 15:49:59 EST 2007
i686 i686 i386 GNU/Linux
# rpm -q nspluginwrapper
nspluginwrapper-0.9.91.5-16.fc8
# rpm -q firefox
firefox-2.0.0.10-3.fc8
# rpm -q flash-plugin
flash-plugin-9.0.115.0-release


Comment 83 Warren Togami 2008-01-25 03:13:04 UTC
Francis, please don't confuse the issue, you are referring to a distinctly
different bug.  Please file a new ticket against nspluginwrapper.

Comment 84 Generic User 2008-01-25 07:50:37 UTC
Sorry about the confusion, Warren.  After taking a closer look, it does appear
that my issue may not necessarily be within nspluginwrapper, but it seems like
there is a pathological interaction among the desktop applets, firefox and
nspluginwrapper.

Thank you for clearing that up.


Comment 85 Derek Hildreth 2008-02-23 15:56:37 UTC
Created attachment 295703 [details]
npviewer.bin report after viewing flash video.

Comment 86 Derek Hildreth 2008-02-23 15:57:52 UTC
Comment on attachment 295703 [details]
npviewer.bin report after viewing flash video.

Running latest updates on Fedora 8 and still consistently getting this crash.

Comment 87 Warren Togami 2008-02-24 19:08:44 UTC
Derek, I have little idea what your npviewer.bin report is pointing at, but it
is definitely not the same problem as this report, and it isn't even clear that
it is describing npviewer at all.

Please file a new bug.

Comment 88 Michael Schwendt 2008-04-05 14:49:13 UTC
*** Bug 422581 has been marked as a duplicate of this bug. ***