Bug 360891
Summary: | (Multithread initialization) Flash player fails when wrapped, works better natively | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Julian Sikorski <belegdol> |
Component: | nspluginwrapper | Assignee: | Martin Stransky <stransky> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | rawhide | CC: | 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
Julian Sikorski
2007-10-31 20:02:33 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) I just confirmed that unwrapped flash works for under f8 as well. 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) 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) Another crasher: http://rezydencja.org 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. 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) Yeah, http://rezydencja.org brings a static page. Flash has been there before. 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. I was having this issue, bug buddy indicated: Could not open library '/usr/lib/kde3/knotify.la'. Installing libkde4 resolved the problem for me cac.wa.us, what you are describing sounds like it has nothing to do with this bug? What's bug #221356? Getting Access Denied here. Was some RHEL customer hit by this? Basically yes. And hmm... Adobe's upcoming 9.0.115 release also crashes when wrapped. =( 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... What you are seeing is the crash. The wrapper crash, not the browser crash. 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 https://bugs.launchpad.net/ubuntu/+source/nspluginwrapper/+bug/141613 Ubuntu's equivalent to this bug. *** Bug 417641 has been marked as a duplicate of this bug. *** 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 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 () 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. 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. 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) Did anybody try to pursue Adobe with this? They have access to Flash source code, so they probably could determine the culprit more easily. 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? (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. 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) > 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?
Mplayerplug-in never crashed for me either. 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) 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. Are you going to chase them to do that? 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? The i386 box is a desktop equipped with P4 3.0E CPU, ICH5 chipset, GeForce fx5700 GPU (nvidia driver). (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. 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. 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. 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. 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.
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
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. 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? 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+"$@"} 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... *** Bug 425984 has been marked as a duplicate of this bug. *** 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). you need to install this one: http://koji.fedoraproject.org/packages/nspluginwrapper/0.9.91.5/14.fc8/ (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?) (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 This does not sound like a fix for single CPU systems, is it ? 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. (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. 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 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. 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) I can confirm that all crashes I was encountering are gone with nspluginwrapper-0.9.91.5-14.fc8. 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. Does not help single processor PII 400Mhz IBM 600 Thinkpad i386 Please follow the instructions in Comment #19 to get a core file then obtain a backtrace. Please attach that backtrace (DO NOT PASTE). 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). "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. How do I make a backtrace? Should I use strace with firefox? (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 I have installed debuginfo package for nspluginwrapper but I have a feeling that gdb misses something. Well, here's what I've got (attached) Created attachment 290235 [details]
npviewer backtrace
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. 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 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. 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 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. (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. 0.9.91.5-15.fc8 seems to work correctly here. No crashes. 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. 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. This one seems to work fine as well. (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. 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. 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' 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. Created attachment 292901 [details]
Bug Buddy's generated npviewer.bin bug report
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 Francis, please don't confuse the issue, you are referring to a distinctly different bug. Please file a new ticket against nspluginwrapper. 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. Created attachment 295703 [details]
npviewer.bin report after viewing flash video.
Comment on attachment 295703 [details]
npviewer.bin report after viewing flash video.
Running latest updates on Fedora 8 and still consistently getting this crash.
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. *** Bug 422581 has been marked as a duplicate of this bug. *** |