registry team mailing list archive
-
registry team
-
Mailing list archive
-
Message #19284
[Bug 333127] Re: Firefox 3.5 and above crash on full screen flash video
Launchpad has imported 40 comments from the remote bug at
https://bugzilla.mozilla.org/show_bug.cgi?id=493541.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
------------------------------------------------------------------------
On 2009-05-18T12:25:03+00:00 Mozilla wrote:
(This is related to bug 473428)
Apparently the jemalloc integration can cause confusion for in process
library functions if libraries are usually not using jemalloc but
referencing malloc() and free() through the processes memory map. (Sorry
I'm not a low level expert).
Here is a bugreport mentioning two examples:
https://bugzilla.novell.com/show_bug.cgi?id=503151
And an explanation I found is:
https://bugzilla.novell.com/show_bug.cgi?id=477061#c11
which led me to this bugreport.
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/11
------------------------------------------------------------------------
On 2009-05-19T10:07:38+00:00 Mozilla wrote:
According to
https://bugzilla.novell.com/show_bug.cgi?id=503151#c5
this is nothing which need to be fixed from mozilla.
Here's the explanation from the above comment:
(and NSS is the glibc's Name Service Switch not Network Security Services)
"
We currently do not support custom malloc() implementation in NSS due to our
patch to open NSS modules deep-bound (that is meant to protect the main process
from library namespace pollution by libraries the NSS module depends on - e.g.
Thunderbird depended on one kind of OpenLDAP library, while nss_ldap depended
on an entirely incompatible one). This causes the main process to use the
custom malloc(), but the NSS module to use the stock free().
"
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/12
------------------------------------------------------------------------
On 2009-06-26T05:48:04+00:00 Karlt wrote:
I'm reopening this, because as well as the name service switch module
loading issues (which show up as bug 473428,
https://bugzilla.novell.com/show_bug.cgi?id=503151 and
https://bugs.gentoo.org/show_bug.cgi?id=252302), the same issue is
affecting the Flash plugin (bug 469439).
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/16
------------------------------------------------------------------------
On 2009-06-26T11:37:25+00:00 Kairo-kairo wrote:
*** Bug 500163 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/17
------------------------------------------------------------------------
On 2009-06-30T08:10:21+00:00 Karlt wrote:
Excepts from what Ulrich Drepper says about the RTLD_DEEPBIND flag he added:
("How To Write Shared Libraries", August 20, 2006,
http://people.redhat.com/drepper/dsohowto.pdf)
this feature should only be used if it cannot be avoided. There are several
reasonse for this:
The change in the scope affects all symbols and all
the DSOs which are loaded. Some symbols might
have to be interposed by definitions in the global
scope which now will not happen.
Already loaded DSOs are not affected which could
cause unconsistent results depending on whether
the DSO is already loaded (it might be dynamically
loaded, so there is even a race condition).
...
The RTLD_DEEPBIND flag should really only be used as
a last resort. Fixing the application to not depend on the
flag's functionality is the much better solution.
The inconsistency that RTLD_DEEPBIND causes with jemalloc is that
dynamic libraries opened with RTLD_DEEPBIND will use libc's malloc while
libc is still using jemalloc. A libc function may return a pointer to
something that should be passed to free, and the dynamic library will
call libc's free, but libc used jemalloc to allocate the memory.
I raised a question on this behavior here:
http://sourceware.org/ml/libc-alpha/2009-06/msg00168.html
But it looks like we can make libc's free (and malloc, etc) use jemalloc:
http://www.gnu.org/s/libc/manual/html_node/Hooks-for-Malloc.html
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/18
------------------------------------------------------------------------
On 2009-07-01T11:02:43+00:00 Karlt wrote:
Created attachment 386244
hook jemalloc into glibc's malloc
I wonder whether we ever build against glibc and expect to run against a
different glibc.
I hoping this will fix the bug but I'm not able to test right now.
The jemalloc dependency in the build system is broken so
OBJ-DIR/browser/app/firefox-bin must be explicitly removed to pick up the changes.
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/21
------------------------------------------------------------------------
On 2009-07-02T07:45:43+00:00 Karlt wrote:
Comment on attachment 386244
hook jemalloc into glibc's malloc
This doesn't work as glibc does not run__malloc_initialize_hook on free.
(The assumption is probably that glibc's malloc or similar would have been
called before free, but that's not happening here.)
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/23
------------------------------------------------------------------------
On 2009-07-02T08:51:59+00:00 Karlt wrote:
Created attachment 386469
hook jemalloc into glibc's malloc (without __malloc_initialize_hook)
We shouldn't need to use __malloc_initialize_hook because the hook
functions will not call glibc malloc functions. This patch uses symbol
interposing to set the 4 hooks.
With this patch, the initial crash of bug 469439 is avoided, but I'm
having trouble testing with my setup here. I get a different (slightly
later) crash with this patch but I seem to get the same crash without
jemalloc, so it may just be related to the hackish way that I've
installed NVIDIA's libGL.
I'd appreciate if someone can help me by testing this patch, please?
You'll need to explicitly remove OBJ-DIR/browser/app/firefox-bin before the build.
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/24
------------------------------------------------------------------------
On 2009-07-02T17:16:23+00:00 Kairo-kairo wrote:
i can confirm that without the patch, a build of SeaMonkey built on top
of 1.9.2 mozilla-central code crashes at print preview while with only
attachment 386469 applied in addition, print preview works fine. Nice
work!
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/25
------------------------------------------------------------------------
On 2009-07-03T03:21:57+00:00 Karlt wrote:
Thanks very much, Robert.
This also fixes bug 469439. (I managed to use the correct libnvidia-
tls.so.1.)
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/28
------------------------------------------------------------------------
On 2009-07-08T19:32:50+00:00 Mozilla wrote:
According to the feedback in
https://bugzilla.novell.com/show_bug.cgi?id=503151 your patch fixes the
issues we've seen.
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/33
------------------------------------------------------------------------
On 2009-07-10T13:20:05+00:00 Veranyon wrote:
I am sorry for my english, but I was sent here from here> http://bugs.archlinux.org/task/15441
I am very weak in programming, not to say that does not know any language. Just wanted to say that I have a problem with the browser when using the macromedia / adobe flash.
Ready to share any technical information that will be required.
Thanks.
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/36
------------------------------------------------------------------------
On 2009-07-23T01:22:22+00:00 Jst wrote:
Given that this causes problems with flash in at least some cases (bug
469439), I think we should fix this for 1.9.2 (and 1.9.1.x as well).
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/37
------------------------------------------------------------------------
On 2009-07-23T01:22:38+00:00 Jst wrote:
*** Bug 469439 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/38
------------------------------------------------------------------------
On 2009-07-23T01:35:42+00:00 Karlt wrote:
#1 Firefox 3.5.1 crash on Linux ATM
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/39
------------------------------------------------------------------------
On 2009-07-23T06:54:38+00:00 Mozilla-bugs-micahscomputing wrote:
Ubuntu Bug:
https://bugs.launchpad.net/bugs/333127
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/41
------------------------------------------------------------------------
On 2009-07-23T10:54:07+00:00 Kairo-kairo wrote:
>From all I hear from the Novell/openSUSE side of things, the patch is
used in builds they ship now and users cheer for it as the problems seem
to be gone.
We really should get this into both 1.9.2 and 1.9.1 ASAP.
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/42
------------------------------------------------------------------------
On 2009-07-23T13:23:37+00:00 Benjamin Smedberg (Mozilla) [:bs] wrote:
Comment on attachment 386469
hook jemalloc into glibc's malloc (without __malloc_initialize_hook)
I don't understand the "elif !defined(malloc) bit here... can you
explain the purpose of that clause?
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/43
------------------------------------------------------------------------
On 2009-07-23T17:25:39+00:00 Samuel-sidler+old wrote:
(In reply to comment #14)
> #1 Firefox 3.5.1 crash on Linux ATM
What is this based on? I don't think it's based on our stats because the
highest crash signature has four crashes in the last week...
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/44
------------------------------------------------------------------------
On 2009-07-23T18:05:42+00:00 Kevin Brosnan wrote:
Based on bug 469439 being marked a dupe of this. Many of the
libc-2.9.so@0x2d097 crashes are crashes when fullscreening flash.
http://crash-
stats.mozilla.com/report/list?product=Firefox&platform=linux&query_search=signature&query_type=exact&query=&date=&range_value=1&range_unit=weeks&do_query=1&signature=libc-2.9.so%400x2d097
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/45
------------------------------------------------------------------------
On 2009-07-23T21:56:08+00:00 Karlt wrote:
Comment on attachment 386469
hook jemalloc into glibc's malloc (without __malloc_initialize_hook)
(In reply to comment #17)
> I don't understand the "elif !defined(malloc) bit here... can you explain the
> purpose of that clause?
I saw this code
/* Mangle standard interfaces on Darwin and Windows CE,
in order to avoid linking problems. */
#if defined(MOZ_MEMORY_DARWIN)
#define malloc(a) moz_malloc(a)
#define valloc(a) moz_valloc(a)
#define calloc(a, b) moz_calloc(a, b)
#define realloc(a, b) moz_realloc(a, b)
#define free(a) moz_free(a)
#endif
http://hg.mozilla.org/mozilla-
central/annotate/55955ee71c10/memory/jemalloc/jemalloc.c#l6126
and assumed that in some cases jemalloc does not replace the system malloc but
is used as an alternative allocator in parallel to the system malloc (used
only in cases where mixing of allocate/free implementations can be avoided).
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/46
------------------------------------------------------------------------
On 2009-07-24T01:50:50+00:00 Pavlov wrote:
(In reply to comment #20)
> (From update of attachment 386469 [details])
> (In reply to comment #17)
> > I don't understand the "elif !defined(malloc) bit here... can you explain the
> > purpose of that clause?
>
> I saw this code
>
> /* Mangle standard interfaces on Darwin and Windows CE,
> in order to avoid linking problems. */
> #if defined(MOZ_MEMORY_DARWIN)
> #define malloc(a) moz_malloc(a)
> #define valloc(a) moz_valloc(a)
> #define calloc(a, b) moz_calloc(a, b)
> #define realloc(a, b) moz_realloc(a, b)
> #define free(a) moz_free(a)
> #endif
>
> http://hg.mozilla.org/mozilla-central/annotate/55955ee71c10/memory/jemalloc/jemalloc.c#l6126
>
> and assumed that in some cases jemalloc does not replace the system malloc but
> is used as an alternative allocator in parallel to the system malloc (used
> only in cases where mixing of allocate/free implementations can be avoided).
on mac they use this zone allocator nonsense, and so malloc calls in to
zone[0] basically and does an allocation. free() loops through each
zone asking if it owns the allocation and then calls free on that zone.
on mac with jemalloc (which we don't actually use at the moment), we
setup a zone and replace the default zone with our own, so we need to
define our functions as something other than malloc, etc. We still
replace the system allocations.
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/47
------------------------------------------------------------------------
On 2009-07-24T02:45:36+00:00 Karlt wrote:
Created attachment 390399
hook jemalloc into glibc's malloc v2.1
Thank you, Stuart for the explanation.
The behavior of this patch is the same as attachment 386469.
The difference is that preprocessor conditionals are moved around a bit to make it clearer when each section is processed.
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/48
------------------------------------------------------------------------
On 2009-07-29T18:30:39+00:00 Matti-mversen wrote:
*** Bug 507161 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/49
------------------------------------------------------------------------
On 2009-07-29T18:50:07+00:00 Toddandmargo wrote:
Is the patch scheduled for 3.5.2?
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/50
------------------------------------------------------------------------
On 2009-07-29T18:59:15+00:00 Samuel-sidler+old wrote:
(In reply to comment #24)
> Is the patch scheduled for 3.5.2?
Not currently, no. A patch has not yet baked on trunk and is, therefore,
not ready to land on the 1.9.1 branch.
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/51
------------------------------------------------------------------------
On 2009-07-30T05:05:59+00:00 Karlt wrote:
http://hg.mozilla.org/mozilla-central/rev/dae91a0884c9
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/52
------------------------------------------------------------------------
On 2009-07-30T05:07:38+00:00 Karlt wrote:
*** Bug 473428 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/53
------------------------------------------------------------------------
On 2009-07-30T12:29:20+00:00 Kevin Brosnan wrote:
Verified - Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre)
Gecko/20090730 Minefield/3.6a1pre
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/54
------------------------------------------------------------------------
On 2009-07-30T16:14:34+00:00 Tyler Downer wrote:
*** Bug 507346 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/55
------------------------------------------------------------------------
On 2009-08-04T21:43:58+00:00 Kevin Brosnan wrote:
*** Bug 508375 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/58
------------------------------------------------------------------------
On 2009-08-10T04:29:38+00:00 Timeless-bemail wrote:
*** Bug 509310 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/59
------------------------------------------------------------------------
On 2009-08-11T22:20:17+00:00 Samuel-sidler+old wrote:
Comment on attachment 390399
hook jemalloc into glibc's malloc v2.1
Approved for 1.9.1.3. a=ss
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/60
------------------------------------------------------------------------
On 2009-08-12T00:28:45+00:00 Karlt wrote:
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/d919708797fa
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/61
------------------------------------------------------------------------
On 2009-08-12T19:27:00+00:00 Theredescorpion wrote:
(In reply to comment #33)
> http://hg.mozilla.org/releases/mozilla-1.9.1/rev/d919708797fa
Hi, I'm from Venezuela and I have this error described here and I see
that here is resolved, but I have not much experience in this and I
don't know exactly what I should do to fix this problem on my machine,
can you help me?
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/62
------------------------------------------------------------------------
On 2009-08-12T20:52:23+00:00 Karlt wrote:
A build with the fix can be downloaded from here:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-1.9.1/
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/63
------------------------------------------------------------------------
On 2009-08-12T22:30:54+00:00 Theredescorpion wrote:
(In reply to comment #35)
> A build with the fix can be downloaded from here:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-1.9.1/
Thanks, but that build is in english and I think that that version is
not an published official version yet, so I can wait when that version
to be published because I already can see the videos in fullscreen by
disabling the hardware acceleration in the configuration of flash
player.
Thank you for your help!!
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/64
------------------------------------------------------------------------
On 2009-09-06T03:31:06+00:00 Kevin Brosnan wrote:
*** Bug 493407 has been marked as a duplicate of this bug. ***
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/66
------------------------------------------------------------------------
On 2009-10-31T02:55:48+00:00 Toddandmargo wrote:
Is this fixed in 3.5.4?
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/73
------------------------------------------------------------------------
On 2009-10-31T04:48:34+00:00 Samuel-sidler+old wrote:
Should have been fixed in 3.5.3 as noted by the .3-fixed entry in the
status1.9.1 field.
Reply at: https://bugs.launchpad.net/firefox/+bug/333127/comments/74
** Changed in: firefox
Importance: Unknown => Critical
** Bug watch added: Novell/SUSE Bugzilla #503151
https://bugzilla.novell.com/show_bug.cgi?id=503151
** Bug watch added: Novell/SUSE Bugzilla #477061
https://bugzilla.novell.com/show_bug.cgi?id=477061
** Bug watch added: Gentoo Bugzilla #252302
http://bugs.gentoo.org/show_bug.cgi?id=252302
--
Firefox 3.5 and above crash on full screen flash video
https://bugs.launchpad.net/bugs/333127
You received this bug notification because you are a member of Registry
Administrators, which is the registrant for Fedora.
