Anyone looking at gnash?

Anyone looking at gnash?

[Isaac Dunham]

[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]

Hello,
I've been poking at gnash on and off, in hopes of having some way to view
Flash on Alpine.
So far, the problem that I know of is it insists on building a malloc that
supports mallinfo (which is used _very_ extensively in gnash).

This is jemalloc, where I've found 3 issues already:
First, it includes the header sys/sysctl.h by default; the #ifdefs around
this are plainly wrong and easily fixed.
Second, it defines issetugid() to 0; this of course breaks due to our
support for the function, and is horrendously wrong (though gnash is unlikely
to be configured in a way where it matters...).
Third, it uses some unsupported pthread stuff: I see
PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP and PTHREAD_MUTEX_ADAPTIVE_NP.
At this point, it's beyond me.

Has anyone else looked at this?

I'm attaching my current WIP patches; less_sysctl.patch is probably correct,
but issetugid.diff is only to get it closer to building on musl and is
massively incomplete.
I hereby release both to the public domain, in case any work based on them
gets pushed upstream.

Thanks,
Isaac Dunham.

[-- Attachment #2: issetugid.diff --]
[-- Type: text/plain, Size: 735 bytes --]

commit f7c796b75df5de91dcc5db10ccf8b2db65bbfbc6
Author: Isaac Dunham <ibid.ag@gmail.com>
Date:   Thu Aug 7 22:24:36 2014 -0700

    issetugid is supported here

diff --git a/libbase/jemalloc.c b/libbase/jemalloc.c
index 9321f59..cdd540f 100644
--- a/libbase/jemalloc.c
+++ b/libbase/jemalloc.c
@@ -190,7 +190,6 @@
 
 #if defined(MOZ_MEMORY_LINUX) && !defined(MOZ_MEMORY_ANDROID)
 #define	_GNU_SOURCE /* For mremap(2). */
-#define	issetugid() 0
 #if 0 /* Enable in order to test decommit code on Linux. */
 #  define MALLOC_DECOMMIT
 #endif
@@ -240,7 +239,6 @@ static unsigned long tlsIndex = 0xffffffff;
 #else
 #define	_pthread_self() __threadid()
 #endif
-#define	issetugid() 0
 
 #ifndef MOZ_MEMORY_WINCE
 /* use MSVC intrinsics */

[-- Attachment #3: less-sysctl.patch --]
[-- Type: text/plain, Size: 439 bytes --]

diff --git a/libbase/jemalloc.c b/libbase/jemalloc.c
index a96333e..9321f59 100644
--- a/libbase/jemalloc.c
+++ b/libbase/jemalloc.c
@@ -326,7 +326,7 @@ __FBSDID("$FreeBSD: head/lib/libc/stdlib/malloc.c 180599 2008-07-18 19:35:44Z ja
 #endif
 #include <sys/time.h>
 #include <sys/types.h>
-#if !defined(MOZ_MEMORY_SOLARIS) && !defined(MOZ_MEMORY_ANDROID)
+#if defined(MOZ_MEMORY_BSD)
 #include <sys/sysctl.h>
 #endif
 #include <sys/uio.h>

Re: Anyone looking at gnash?

[Rich Felker]

On Thu, Aug 07, 2014 at 10:56:38PM -0700, Isaac Dunham wrote:
> Hello,
> I've been poking at gnash on and off, in hopes of having some way to view
> Flash on Alpine.
> So far, the problem that I know of is it insists on building a malloc that
> supports mallinfo (which is used _very_ extensively in gnash).

What does it need mallinfo for? I suspect you can just provide a fake
one that gives some estimates based on /proc, or rip it out
alltogether.

> This is jemalloc, where I've found 3 issues already:

The fourth issue is much bigger: replacing malloc is UB and does not
work, especially not on musl. :-)

Trying to make jemalloc work is going to be a dead-end. And I don't
see how a plug-in could think it could replace malloc anyway, even on
systems that (attempt to) allow it. As a plugin, it (or at least the
part that works as a loadable module) has to use whatever malloc is
already there in the process that loaded it (the web browser).

Anyway, back to the point: just fixing gnash to eliminate this
requirement is the direction you want to take.

BUT:

If you don't have an aversion to using the flash player binary, it's
reported to work with musl with a minimum amount of hackery to get it
to load. I'm going to try to get the user who's worked on this to
document the process and post it somewhere. Supposedly he's used it
successfully with both Chromium and Firefox on x86_64 Alpine.

Rich

Re: Anyone looking at gnash?

[Natanael Copa]

On Fri, 8 Aug 2014 02:08:18 -0400
Rich Felker <dalias@libc.org> wrote:

> 
> BUT:
> 
> If you don't have an aversion to using the flash player binary, it's
> reported to work with musl with a minimum amount of hackery to get it
> to load. I'm going to try to get the user who's worked on this to
> document the process and post it somewhere. Supposedly he's used it
> successfully with both Chromium and Firefox on x86_64 Alpine.

Might also be worth to mention that I have tried gnash on uclibc and
that never worked very well.

-nc

Re: Anyone looking at gnash?

[Isaac Dunham]

On Fri, Aug 08, 2014 at 02:08:18AM -0400, Rich Felker wrote:
> On Thu, Aug 07, 2014 at 10:56:38PM -0700, Isaac Dunham wrote:
> > Hello,
> > I've been poking at gnash on and off, in hopes of having some way to view
> > Flash on Alpine.
> > So far, the problem that I know of is it insists on building a malloc that
> > supports mallinfo (which is used _very_ extensively in gnash).
> 
> What does it need mallinfo for? I suspect you can just provide a fake
> one that gives some estimates based on /proc, or rip it out
> alltogether.
I haven't really gotten the picture, and all I can say is that I don't know
enough C to fix gnash (whether it's writing a fake mallinfo or removing the 
mallinfo dependency).
<snip>
> BUT:
> 
> If you don't have an aversion to using the flash player binary, it's
> reported to work with musl with a minimum amount of hackery to get it
> to load. I'm going to try to get the user who's worked on this to
> document the process and post it somewhere. Supposedly he's used it
> successfully with both Chromium and Firefox on x86_64 Alpine.

Really, I'm quite fine with that. I just didn't expect it to be possible.


Thanks,
isaac Dunham