Bug 10829

Summary:	incorrect link options cause mozilla plugin crash on FreeBSD/amd64
Product:	swfdec	Reporter:	Bill Paul <wpaul>
Component:	library	Assignee:	Eric Anholt <eric>
Status:	RESOLVED FIXED	QA Contact:	Eric Anholt <eric>
Severity:	blocker
Priority:	medium	CC:	otte
Version:	unspecified
Hardware:	x86-64 (AMD64)
OS:	FreeBSD
Whiteboard:
i915 platform:		i915 features:

Description Bill Paul 2007-05-01 15:49:20 UTC

The other day, in a fit of boredom, I decided to try swfdec. I have a Sun w2100z dual Opteron system running FreeBSD 6.2-RELEASE for amd64, and I'm using Firefox 1.5.0.8. After rummaging around for all the various dependent packages, I managed to get the library and the mozilla plugin built. However, the plugin would always crash Firefox when I tried to play any .swf movies. Trying to run the same .swf files using swfplay from the command line seemed to work, however.

It turns out that the problem has to do with the fact that swfdec includes its own custom copy of the javascript library which, due to the way libswfdec.so is linked (and due to the behavior of the FreeBSD runtime linker), clashes with the javascript library in Firefox proper. For example, when swfdef was calling JS_NewFunction(), it was actually calling the version in libmozjs.so from Firefox instead of the internal version in libswfdec.so. This doesn't work, because swfdec's local copy has many internal structure differences compared to the Firefox version: while the main API function names are the same, the APIs themselves are incompatible. In my case, the crash would happen in js_AtomizeString(), because it tries to dereference the 'runtime' pointer in the javascript context structure, which is in a different location in swfdec's local version of javascript. (The field where Firefox's js_AtomizeString() looks for the runtime pointer is set to 0, and dereferencing that causes a crash.)

In order to get the right behavior, I had to modify the build scripts (specifically libtool) to force libswfdec.so to be linked with -Wl,-Bsymbolic. This causes all global symbol references within the library to be resolved aginst the library itself (so when swfdec references JS_NewFunction(), it gets linked against its own copy of JS_NewFunction(), instead of the one in Firefox). The build scripts already prevent the internal javascript routines from being exported, so nothing else can see them.

I'm not sure why this doesn't cause a problem on Linux. Both Linux and FreeBSD use GNU ld, and the Linux version does seem to also support -Bsymbolic as well. It could be that FreeBSD's runtime linker behavior is buggy, or it could be that Linux's runtime linker is extra careful, or it could be some peculiarity in libtool. (It could also be specific to the FreeBSD/amd64 linker: I haven't tried it on FreeBSD/ia32 yet.) At this point, I don't even know if swfdec has been tested on anything besides Linux, so maybe nobody even cares. :)

It might be a good idea to insure that the build scripts force the use of -Wl,-Bsymbolic though, just so there's no ambiguity.

Comment 1 Benjamin Otte 2007-05-03 09:52:39 UTC

As far as I know this has worked before, we've been careful to not export the Javascript symbols since Swfdec uses a modified version of the Mozilla JS engine internally. Eric should know more about this since he's the FreeBSD guy.

I'd guess it's either a libtool issue or some included library's CFLAGS are to blame.
Libswfdec makes sure to not export the Javascript symbols passing --export-symbol-regex=swfdec_.* to libtool when building the library. However, since the Javascript part is built as a noinst_LIBRARY and then linked statically into libswfdec, the linkig has to happen without --export-dynamic which it normally does. However some libraries swfdec depends on (in particular gmodule via GStreamer) used to include this option. I thought I got rid of that by requiring GStreamer >= 0.10.11 where this was fixed.

Maybe something there is different on FreeBSD?

Comment 2 Bill Paul 2007-05-04 14:21:14 UTC

The thing is, it's not a question of exporting the javascript symbols out of libswfdec. I saw the --export-symbol-regex=swfdec_.* option, and yes, it has the intended effect: if you do "nm libswfdec-0.4.so", you'll only see swfdec symbols listed.

But that's not the problem. Say I write a program which uses libmozjs.so. I correctly use the header files that go with libmozjs.so, so the API matches up. Now I want to link my program with libswfdec-0.4.so too. When I link my program, the linker will not see the JS_* routines in libswfdec-0.4.so because those symbols aren't exported. That's fine.

The problem is when libswfdec-0.4.so itself is linked. The --export-symbol-regex=swfdec_.* does not affect what the linker does when it binds all the objects from swfdec and js/libjs.a together into libswfdec-0.4.so: it only affects what will happen when libswfdec-0.4.so is linked with other programs later. For example, say swfdec_script.o has a reference to JS_NewContext() (which I think it does). Without -Bsymbolic, the linker will not resolve that reference when the library is created: instead, it will leave the reference unresolved and rely on the runtime linker to deal with it later. In this case, the symbol is resolved when the plugin is loaded into Firefox, and at that point, the runtime linker can only find one instance of JS_NewFunction, which is in libmozjs.so. That's the wrong one, so the code crashes.

Using -Bsymbolic changes the behavior: now the linker will resolve swfdec_script.o's reference to JS_NewFunction when libswfdec-0.4.so is created, so that runtime binding won't be necessary. And *then* --export-symbol-regex=swfdec_.* prevents the JS_* symbols from being exported. This insures that swfdec will use the right javascript engine, and that nobody else will be able to use it.

It's possible that --export-symbol-regex=swfdec_.* on Linux implies -Bsymbolic as well. But again, it may be a good idea to specify -Bsymbolic explicitly in order to avoid any ambiguity.

Comment 3 Benjamin Otte 2007-05-14 08:25:46 UTC

I'm a bit scared of adding random linker options, because that might break different operating system's builds. Otherwise I would have added it already.

I don't know why it causes issues for you, but I know Eric ran Swfdec on FreeBSD. But I have no idea if he ran 0.4 as a Mozilla plugin yet.

Comment 4 Eric Anholt 2007-05-15 10:58:12 UTC

The mozilla plugin has been a total crashfest on FreeBSD, and I never tracked it down.  The fix given sounds like the right thing to do.

Comment 5 Benjamin Otte 2007-05-17 04:53:19 UTC

I've looked around a bit for sanely written configure.ac code detecting required usage of -Bsymbolic but didn't find any.
I'm not sure how other OSs behave
And since I plan on removing the moz bits anyway, I guess a simple switch that detects FreeBSD (or whatever) and adds -Bsymbolic to the linker options in configure.ac is fine.

Any BSD person wants to provide a patch?

Comment 6 Benjamin Otte 2007-07-11 07:51:12 UTC

This should be fixed since 0.4.5, configure now adds -Bsymbolic unconditionally.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.