cannot open Firefox/Chromium/Google Chrome when libmoon is installed

Bug #538796 reported by executorvs
578
This bug affects 114 people
Affects Status Importance Assigned to Milestone
Chromium
Unknown
Unknown
Moonlight Plugin Mozilla
Won't Fix
Critical
moon (Ubuntu)
High
Unassigned
Karmic
High
Unassigned
Lucid
High
Unassigned
Maverick
High
Unassigned
Natty
High
Unassigned

Bug Description

after installing Shockwave via mozplugger I deleted pluginreg.dat and tried to boot firefox. as opposed to auto-generating the file, firefox crashes. after running firefox in terminal noticed "user@SDF-1:~$ firefox
Attempting to load the system libmoon
Segmentation fault (core dumped)"

proceeded to uninstall moon packages and firefox then behaves as intended.

after doing a clean install I attempted to recreate the bug without the presence of other non-default packages and proceeded to install moonlight and then deleted pluginreg.dat from firefox to the same results.

I am using the current 3/13/10 daily-build of lucid 64bit
I apologize for the lack of an apport bug report but it doesn't seem to be working right now.

executorvs (executorvs)
tags: added: crash firefox lucid moonlight ubuntu
Revision history for this message
Micah Gersten (micahg) wrote :

Thank you for reporting this to Ubuntu. Why are you deleting pluginreg.dat?

Changed in moon (Ubuntu):
status: New → Incomplete
Revision history for this message
executorvs (executorvs) wrote :

because otherwise firefox doesn't, or didn't, seem to properly detect shockwave as installed via mozplugger and wine. It was a step needed in karmic and earlier releases, I haven't tried skipping it in lucid. I don't think it's highly likely many other people will encounter a need to do so. With the exception of a few school websites I've seen very little that still needs shockwave as opposed to flash.

Revision history for this message
executorvs (executorvs) wrote :

the walkthrough on installing shockwave is located at https://help.ubuntu.com/community/Shockwave

Revision history for this message
executorvs (executorvs) wrote :

Apparently at least with jaunty and firefox 3 you no longer need to delete the plugin database to get it to reload with mozplugger. I'll play with that later to see if it holds for lucid. what libmoon does just so I'm clear is prevent firefox from generating a new database if for some reason it is removed after moonlight has been installed and thus firefox crashes upon restart. the simple fix is to uninstall libmoon allow firefox to remake the pluginreg.dat file and then reinstall moonlight.

sorry about the multiple posts.

Revision history for this message
Hamish Downer (mishd) wrote :

I had firefox start to crash today. I've just uninstalled libmoon (and moonlight-plugin-core and moonlight-plugin-mozilla as they depend on it) and firefox works fine again. I have an apport report, but it is 156MiB so I might just upload the report from /var/crash/ instead. Let me know if you want the full apport report.

I have not done any messing around with pluginreg.dat and I don't use shockwave - I use the Adobe Flash Player (64 bit beta) and have had no problems with that.

I had the same error when attempting to run from the command line:

Attempting to load the system libmoon
Segmentation fault (core dumped)

1 comments hidden view all 116 comments
Revision history for this message
executorvs (executorvs) wrote :

shockwave is different from Flash and used for other applications. had you installed anything to firefox before it started crashing?

Revision history for this message
Hamish Downer (mishd) wrote :

In my case I upgraded to Lucid a couple of weeks ago and firefox worked fine until today. I had made no changes to my firefox set up recently. I use a few different firefox profiles and all the ones I tested were affected, and they all work fine following the removal of libmoon et al. The simplest profile I tested has only the Adblock Plus add on installed and is otherwise a pretty standard set up.

Revision history for this message
executorvs (executorvs) wrote :

were any of the plugins auto updated? ubufox or gnome-firefox (the integration package for firefox with gnome) maybe? any functional plugin update might cause the plugin database to be updated.

when I get home I'll try installing something like flash and see if it causes a crash. I'm going to copy the plugin database and if it crashes after installing flash I'll compare the before and after copies which should let me know if firefox successfully edits the database.

Revision history for this message
Hamish Downer (mishd) wrote :

I've just reinstalled moonlight-plugin-mozilla (together with libmoon of course) to check the crash again, but firefox is now happy again. Maybe there was a bug in one of the lower libraries that caused libmoon to fail that has since been fixed by one of the updates?

I'll stay subscribed, but unless I say more in another comment then this bug is fixed for me.

Revision history for this message
executorvs (executorvs) wrote :

I find the bug is still reproducible. anything that causes firefox to rebuild it's plugin database after libmoon is installed causes it to crash. libmoon doesn't seem to trigger a rebuild normally. the gnome integration plugin and mozplugger seem to, I'm not sure what else might.
I meant to check flash last night but I've been side tracked between my genetics and chinese. I should have all afternoon thursday and a good chunk of friday to try and narrow it down. I may reinstall then and see if I can fix apport so I can attach some bug reports.

Revision history for this message
Bruce Miller (brm0423) wrote :

I did not intentionally or knowingly install libmoon. I have just got my 64-bit machine back from the shop after replacing a dead data drive and installed Lucid beta --- the first time that I have had Lucid on this machine. I tend to run a wide range of applications and have therefore installed many packages after installing from the CD. Clearly libmoon got pulled in along the way.

The large crash report from /var/crash is attached.

firefox worked fine before the large installation session. Afterwards:
bruce@Xenophon:~$ firefox
Attempting to load the system libmoon
Segmentation fault (core dumped)
bruce@Xenophon:~$

My basic setup is this:

bruce@Xenophon:~$ uname -a
Linux Xenophon 2.6.32-16-generic #25-Ubuntu SMP Tue Mar 9 16:33:12 UTC 2010 x86_64 GNU/Linux
bruce@Xenophon:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu lucid (development branch)
Release: 10.04
Codename: lucid
bruce@Xenophon:~$ apt-cache policy libmoon
libmoon:
  Installed: (none)
  Candidate: 2.2-0ubuntu1
  Version table:
     2.2-0ubuntu1 0
        500 http://ca.archive.ubuntu.com/ubuntu/ lucid/universe Packages
bruce@Xenophon:~$

Changed in moon (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Bruce Miller (brm0423) wrote :

I have taken the liberty of changing the status of this bug report from Incomplete to Confirmed.

It is reported as affecting several users. Two of them have uploaded the automatically generated crash report.

Revision history for this message
Yahuhanan (יהוחנן) Yukia (雪亮) Sese (謝) Cuneta (techmagus) wrote :

I experience this also, however, only if "moonlight-plugin-mozilla" is installed. As long as it is not installed, Firefox doesn't crash a few seconds after starting it up. (I left libmoon and moonlight-plugin-core still installed, I only removed moonlight-plugin-mozilla).

Versions: (as of March 27, 2010 9:13pm UTC+0800H)
Firefox 3.6+nobinonly-0ubuntu6 (lucid)
libmoon 2.2-0ubuntu1
moonlight-plugin-core 2.2-0ubuntu1
moonlight-plugin-mozilla 2.2-0ubuntu1

Tested on Lucid Netbook32. Haven't tested on Lucid Desktop64.

No other changes or steps taken, just a simple installation of moonlight. Firefox loads, a few seconds after (10secs usually), Firefox crashes. I didn't get any apport pop-up tho.

Revision history for this message
3vi1 (launchpad-net-eternaldusk) wrote :

I can confirm what JC experienced. I had renamed my .mozilla directory and found FF crashing everytime I tried to start it "clean". After I removed moonlight-plugin-mozilla, it starts normally. This is on the AMD64 lucid.

Revision history for this message
Micah Gersten (micahg) wrote :

I deleted the attached .crash files as they might contain personal information. Please file a new bug using ubuntu-bug and the path to the crash file. This will allow the retracer to determine if the bugs are the same.

Revision history for this message
Kim Botherway (dj-dvant) wrote :

I found that doing:
1. apt-get purge moonlight-plugin-core moonlight-plugin-mozilla
2. Start firefox
3. Exit firefox
4. apt-get install moonlight-plugin-core moonlight-plugin-mozilla
5. Start firefox fixes the problem for me. Have reproduced the fix twice now:

First crash:
kbotherway@kim-touch:~$ firefox
Attempting to load the system libmoon
Segmentation fault (core dumped)

After removing moonlight plugins:
kbotherway@kim-touch:~$ firefox
OpenOffice path is '/usr/lib/openoffice'

After reinstalling the plugins:
kbotherway@kim-touch:~$ firefox
Attempting to load the system libmoon

Revision history for this message
Kim Botherway (dj-dvant) wrote :

However, the fix above doesn't last after a reboot, I have to remove the plugin again...

Revision history for this message
funicorn (funicorn) wrote :

I ran into this bug after I installed the moonlight plugin for firefox. And the problem is gone after I remove moonlight. Then I tried to reinstall moonlight, so far so good.

Revision history for this message
executorvs (executorvs) wrote :

This bug has been addressed in the development version of moonlight found at http://go-mono.com/moonlight/prerelease.aspx maybe someone wiser than I could talk to the developers at the mono-project and create a patch.. for the past few weeks I have been using the previous test release with no ill effect.

Revision history for this message
John Winterton (jwinterton) wrote :

I reported this without finding it in the list as 573283. Look at this to see my user scenario.

I am an old O/S programmer, but now long retired and haven't kept up. Good luck with this, fellows.

I don't currently need this plugin, but would be happy to use it if it gets fixed.

Revision history for this message
Bump (bump55) wrote :

Uninstall moonlight-plugin-mozilla and install this:

http://go-mono.com/moonlight/prerelease.aspx

It does not crash at least.

Revision history for this message
pointydrip (pointydrip) wrote :

In my case firefox (with libmoon) crashed upon upgrading to Lucid. Removing libmoon fixed it.

Revision history for this message
hofmannd (dh-denishofmann) wrote :

Same problem and same solution as poitydrip...but...
All Ubuntu user's aren't gurus !!!
As ubuntu fan, I purpose to all people I know to switch to free software, preferabily on Ubuntu and chose also LTS vers.
It's a very important bug when std apps, as browser doesn't work fine after upgrade !!!
Same bugs are to maintain free software and ubuntu as confidential apps.
I doubt that's Canonical's target.

Revision history for this message
Michael Jonker (citizen-jonker) wrote :

Can also confirm on Lucid 64 bit.

I un-install all the moonlight (libmoon and plugin) then run firefox perfectly. I then reinstall moonlight and firefox runs perfectly. But, alas - when I create a new user the problem is back in their account and I have to do the un-install - reinstall trick again!

Not a problem for me, but very confusing for the non-technical users who don't know. I suggest not installing moonlight for any standard users until this is confirmed fixed.

Revision history for this message
bereshit (vendetta7) wrote :

1. apt-get purge moonlight-plugin-core moonlight-plugin-mozilla
2. Start firefox
3. Exit firefox
4. apt-get install moonlight-plugin-core moonlight-plugin-mozilla
5. Start firefox fixes the problem for me.

50 comments hidden view all 116 comments
Revision history for this message
In , Fayaboom (fayaboom) wrote :

This is the only way I used to make it run normally

Revision history for this message
In , Timeless-bemail (timeless-bemail) wrote :

(In reply to comment #8)
Program received signal SIGSEGV, Segmentation fault.
0xa7a88209 in ?? () from
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0/jre/lib/i386/IcedTeaNPPlugin.so

This is the good one. You can see that IcedTea crashed.

As for why zypper is misbehaving, that's a problem which belongs to opensuse's bug tracker, not ours.

WRT tracking down problems w/ IcedTea, I'd request that you use either openSuse's bug tracker or IcedTea's (openSuse's is the better choice if you installed IcedTea from openSuse).

Revision history for this message
In , Mozilla (mozilla) wrote :

I really recommend to not use IcedTeaNPPlugin.so anywhere at the moment.
There was a crash reported for Firefox a long time ago with it and it apparently strikes back here in Thunderbird.

Revision history for this message
In , Fayaboom (fayaboom) wrote :

Ok guys!!

Thunderbird is crashing in its main function. The debuggers don't manage to help us. I don't know howto not use IcedTeaNPPlugin.so.

I followed the advise of Wolfgang Rosenauer. The B plan.
I upgraded to the 3.1.1 version of thunderbird.
And now, everything goes right.
Maybe Thunderbird 3.1.1 does not use this plugin.
Now I can return to my favorite O.S. quietly
Thank you to all for all in the bug handling staff

;-)

Revision history for this message
In , Timeless-bemail (timeless-bemail) wrote :

the debugger did help. it clearly fingered icedtea. the easiest way to not use icedtea is to uninstall it.

Revision history for this message
In , Vseerror (vseerror) wrote :

overall #94 crash for Thunderbird v3.1.1 - sig IcedTeaPlugin.so@0x873c

that's pretty amazing for a linux-only crash

Revision history for this message
In , Dveditz (dveditz) wrote :

How is Java being loaded by Thunderbird? Does Thunderbird load plugins these days? They used to be disabled.

Revision history for this message
In , Dveditz (dveditz) wrote :

If this is a Tbird Linux topcrash maybe we should reopen this bug, and either work around it, fix whatever we recently changed (we're seeing a spike in FF3.6.9pre also), or work with the IcedTea people to fix it.

Revision history for this message
In , Fayaboom (fayaboom) wrote :

Howto reopen it thus ?

Revision history for this message
In , Standard8 (standard8) wrote :

(In reply to comment #17)
> How is Java being loaded by Thunderbird? Does Thunderbird load plugins these
> days? They used to be disabled.

Thunderbird will load/access the list of plugins, however unless mailnews.message_display.allow.plugins is set to true, the content policy will block loading the plugin object into the plugin.

So if we're suggesting a binary compatibility issue on load (that maybe 586543 is) then we're liable to hit that.

Revision history for this message
In , Fayaboom (fayaboom) wrote :

Created attachment 466929
Another segmentation error from Thunderbird 3.06 under OpenSUSE 11.3

59 comments hidden view all 116 comments
Revision history for this message
Mzombira (mzombira) wrote :

this bug is afecting me too and I'm on ubuntu 10.10
if libmoon is installed firefox crash at launch
but if I remove it ( from synaptic) firefox work fine aigain
and I don't play with some plugin database or something like that

Revision history for this message
Gerwin (gerwin-kramer) wrote :

I have this bug too, but not in Firefox (minefield) but in Chromium and Chrome (on Maverick)

Uninstalling libmoon solved the problem.

summary: - cannot open Firefox when libmoon is installed
+ cannot open Firefox/Chromium/Google Chrome when libmoon is installed
Fabien Tassin (fta)
Changed in chromium:
status: New → Invalid
Changed in moon (Ubuntu):
importance: Undecided → High
Revision history for this message
Fabien Tassin (fta) wrote :
58 comments hidden view all 116 comments
Revision history for this message
In , Chris Coulson (chrisccoulson) wrote :

We're seeing a lot of these crashes in Ubuntu too.

When I ran it through GDB, the line number at the top of the stack lined up with a call to getenv in the icedtea plugin, which I thought was strange. If I uninstall the moonlight plugin, the crash goes away, which makes me think that the moonlight plugin actually has some memory corruption issues, and the icedtea plugin is just an innocent victim of those.

Looking through this report, I see several people have moonlight installed....

57 comments hidden view all 116 comments
Revision history for this message
Chris Coulson (chrisccoulson) wrote :
Revision history for this message
Andyr (andy-j-ridout) wrote :

Same problem - Segmentation fault of Google Chrome and Chromium on libmoon.
Un-installed moonlight using synaptic and the problem has gone away.
Firefox was uaffected.
Google Chrome 6.0.472.63
Chromium 6.0.472.63 Ubuntu 10.10
uname -a
>> Linux Kryten 2.6.35-22-generic #33-Ubuntu SMP Sun Sep 19 20:32:27 UTC 2010 x86_64 GNU/Linux
Maverick Meercat obviously

Revision history for this message
Michael G. Vlachos (mgvlachos) wrote :

I had lucid with moonlight (libmoon) installed, chrome and firefox (minefield) working just fine and chromium crashes. After upgrading to maverick only firefox (minefield) working fine, chrome not even open and chromium still crashes. After removing moonlight all browsers working just fine. But is there a way to vercome this?

Revision history for this message
Bruce Crowther (bwucie) wrote :

Have just installed Maverick on my desktop (64 Bit) and both Google Chrome and Chromium crashed immediately after launching (but Chrome works fine on my 32 Bit netbook - go figure).

I removed Moonlight as per Michael's post, and Chromium now runs fine.

Revision history for this message
Michael G. Vlachos (mgvlachos) wrote :

But is there any way to run chorme/chromium without removing moonlight?

Revision history for this message
Michael B (a-b-c) wrote :

Installed ubuntu 10.04
switched to kubuntu having root- and one user account installed
moon plugin and libs were installed
no problem to start firefox with either account
created a new user account
firefox crashed always
purged all moon packages completely (inclusive config files)
firefox started with all accounts
(re-) installed moon plugin
firefox started with all accounts

remarks:
after first time installing new user account that account had one "id-directory" inside the ~./mozilla/extensions folder while root and other account had two, even after purging and reinstalling all linked extensions.

On problems it may help to start firefox from console with "firefox -safe-mode" and "firefox" to see error messages.

Maybe the (k)ubuntu integration of the moon plugin is the basic reason (libmoon is still labeled unstable but that does not hinder ff to start at all) ?

Revision history for this message
Jaroslav Šmíd (jardasmid-gmail) wrote :

moonligh crashes chromium browser, "works" fine in firefox though:

Attempting to load the system libmoon
Segmentation fault

Revision history for this message
carloslp (carloslp) wrote :

The same happens here. I have generated the core and attaching the output of

gdb -ex "thread apply all bt" --batch /usr/lib/chromium-browser/chromium-browser /tmp/core

Revision history for this message
tilteffect (steven-cote) wrote :

Just to add to the stack trace in comment #37, I installed the dbg packages and generated the same segfault. The important extra information is:

Attempting to load the system libmoon

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb4eaab70 (LWP 10083)]
0xa9b50cfc in __static_initialization_and_destruction_0 () at /build/buildd/openjdk-6-6b20-1.9.1/build/../plugin/icedteanp/IcedTeaNPPlugin.cc:237
237 /build/buildd/openjdk-6-6b20-1.9.1/build/../plugin/icedteanp/IcedTeaNPPlugin.cc: No such file or directory.
 in /build/buildd/openjdk-6-6b20-1.9.1/build/../plugin/icedteanp/IcedTeaNPPlugin.cc
(gdb) bt
#0 0xa9b50cfc in __static_initialization_and_destruction_0 () at /build/buildd/openjdk-6-6b20-1.9.1/build/../plugin/icedteanp/IcedTeaNPPlugin.cc:237
#1 global constructors keyed to IcedTeaNPPlugin.cc(void) () at /build/buildd/openjdk-6-6b20-1.9.1/build/../plugin/icedteanp/IcedTeaNPPlugin.cc:2439
#2 0xa9b6f68d in __do_global_ctors_aux () from /usr/lib/jvm/java-6-openjdk/jre/lib/i386/IcedTeaPlugin.so
#3 0xa9b4fb68 in _init () from /usr/lib/jvm/java-6-openjdk/jre/lib/i386/IcedTeaPlugin.so

... rest of backtrace snipped.

Of particular interest is that the segfault seems to actually be happening in the icedtea plugin. Like everyone else that's posted above, this only occurs when libmoon is installed. At least there's a file/line number to look at now.

Revision history for this message
ledom (sebdomeny) wrote :

Affect me today with new daily build firefox 4
Uninstall monnlight and libmoon solve the problem

Revision history for this message
stenzn (stenzn) wrote :

natty amd64

Firefox loads fine for me, but chromium-browser gives the same segmentation fault attempting to load libmoon. Removing libmoon and associated plugins fixed it.

48 comments hidden view all 116 comments
Revision history for this message
In , Scoobidiver (scoobidiver) wrote :

It also happens in Firefox 4.0b9, mainly close to startup.
Other similar (same stack traces) signatures are IcedTeaPlugin.so@0x866c, IcedTeaPlugin.so@0x7cfc and IcedTeaPlugin.so@0x85fc.
With the 4 combined signatures, it is #1 top crasher on Linux in 4.0b9 for the last week. It counts for 16% of all crashes.

Frame Module Signature [Expand] Source
0 IcedTeaPlugin.so IcedTeaPlugin.so@0x873c
1 IcedTeaPlugin.so IcedTeaPlugin.so@0x26f3c
2 IcedTeaPlugin.so IcedTeaPlugin.so@0x75a7
3 ld-2.11.1.so ld-2.11.1.so@0xdbbb
4 ld-2.11.1.so ld-2.11.1.so@0xdcd8
5 ld-2.11.1.so ld-2.11.1.so@0x11d98
6 ld-2.11.1.so ld-2.11.1.so@0xd7e5
7 ld-2.11.1.so ld-2.11.1.so@0x115e5
8 libdl-2.11.1.so libdl-2.11.1.so@0xc0a
9 ld-2.11.1.so ld-2.11.1.so@0xd7e5
10 libdl-2.11.1.so libdl-2.11.1.so@0x109b
11 libdl-2.11.1.so libdl-2.11.1.so@0xb40
12 libnspr4.so PR_LoadLibraryWithFlags prlink.c:836
13 libxul.so nsPluginFile::LoadPlugin modules/plugin/base/src/nsPluginsDirUnix.cpp:312
14 libxul.so nsPluginFile::GetPluginInfo modules/plugin/base/src/nsPluginsDirUnix.cpp:345
15 libxul.so nsPluginHost::ScanPluginsDirectory modules/plugin/base/src/nsPluginHost.cpp:2100
16 libxul.so nsPluginHost::ScanPluginsDirectoryList modules/plugin/base/src/nsPluginHost.cpp:2235
17 libxul.so nsPluginHost::FindPlugins modules/plugin/base/src/nsPluginHost.cpp:2323
18 libxul.so nsPluginHost::LoadPlugins modules/plugin/base/src/nsPluginHost.cpp:2258
19 libxul.so nsPluginHost::GetPluginCount modules/plugin/base/src/nsPluginHost.cpp:1586
20 libxul.so nsPluginArray::GetLength dom/base/nsPluginArray.cpp:89
21 libxul.so nsMimeTypeArray::GetMimeTypes dom/base/nsMimeTypeArray.cpp:242
22 libxul.so nsNavigator::JavaEnabled dom/base/nsGlobalWindow.cpp:10718

More reports at:
http://crash-stats.mozilla.com/query/query?product=Firefox&version=&version=Firefox%3A4.0b9&platform=linux&date=&range_value=1&range_unit=weeks&query_search=signature&query_type=startswith&query=IcedTeaPlugin.so&do_query=1

Revision history for this message
In , Philip-chee (philip-chee) wrote :

*** Bug 627314 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Timeless-bemail (timeless-bemail) wrote :

scooby: there's no point in moving a bug from plugins to core. if you want to blocklist a plugin, file a tiny bug with a dependency to the long bug.

we're crashing deep in initialization of icedtea, which makes the crash clearly a bug in the plugin.

Revision history for this message
In , Timeless-bemail (timeless-bemail) wrote :

note that bug 586543 covers the possibility that it's our fault in some interesting way, that bug is already in core, so if you need to use a bug in core to set a blocking flag, just use that one.

Revision history for this message
In , Benjamin Smedberg (Mozilla) [:bs] (benjamin-smedbergs) wrote :

Please leave this bug in Core, it's a valid nomination and the plugins product is a load of crap. I don't know whether we will block on this, but I don't want to deal with blocking noms in an older bug that is mostly unrelated to the current topcrash.

Revision history for this message
In , Chris Coulson (chrisccoulson) wrote :

Please don't blacklist the icedtea plugin (see comment #22), I'm sure the real issue is the moonlight plugin (libmoon.so). Sorry, I was going to report a bug in to their tracker about it but it totally slipped my mind.

Last time I checked, I could recreate this freely on my system with moonlight installed (libmoon.so plugin loads, then icedtea plugin loads and it's initializer calls getenv, where it crashes)

Revision history for this message
In , Chris Coulson (chrisccoulson) wrote :

See also - http://code.google.com/p/chromium/issues/detail?id=49743 (Chromium crashes when moonlight and icedtea are both installed)

Revision history for this message
In , Chris Coulson (chrisccoulson) wrote :

Also http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=472 might be relevant, and that is also linking to this report

Revision history for this message
In , Timeless-bemail (timeless-bemail) wrote :

So, this is the relevant bit from icedtea's report <http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=472#c0>:

#3 0x00007f6e95f27406 in malloc_printerr (action=3, str=
    0x7f6e95fd5bf0 "double free or corruption (!prev)",
    ptr=<value optimized out>) at malloc.c:6264
#4 0x00007f6e95f2c1ac in *__GI___libc_free (mem=...)
    at malloc.c:3738
#5 0x00007f6e7b3bcff8 in plugin_test_appletviewer (
    browserTable=..., pluginTable=...)
    at
/var/tmp/paludis/dev-java-icedtea-6.1.8.0/work/icedtea6-1.8/plugin/icedteanp/IcedTeaNPPlugin.cc:1517
        command_line = {
    0x1b83850 "/usr/lib64/icedtea6/jre/lib/amd64/../../bin/java",
    0x9afe40 "-version", 0x0}
        environment = 0x1b759b0
#6 NP_Initialize (browserTable=...,
/var/tmp/paludis/dev-java-icedtea-6.1.8.0/work/icedtea6-1.8/plugin/icedteanp/IcedTeaNPPlugin.cc:2156
    0x1bb4180 "/usr/lib64/icedtea6/jre/lib/amd64/IcedTeaPlugin.so",

Revision history for this message
In , Timeless-bemail (timeless-bemail) wrote :

https://bugs.launchpad.net/ubuntu/+source/moon/+bug/538796 is also rather confident in blaming libmoon for this.

Revision history for this message
In , Smooney (smooney) wrote :

Johnny, while bsmedbergs out, do you want to comment on this one?

Revision history for this message
In , Jst (jst) wrote :

Sounds like we need to block list the moonlight plugin here. I've filed bug 629544 on the block listing.

I'm not going to hold the release for this issue though.

Revision history for this message
In , Evan Martin (Chromium) (evan-chromium) wrote :

I did some digging.

http://code.google.com/p/chromium/issues/detail?id=49743#c55 summarizes it, and in particular http://code.google.com/p/chromium/issues/detail?id=49743#c46 has the smoking gun. I think we want to blacklist old versions of icedtea, and leave moonlight alone.

Revision history for this message
In , Evan Martin (Chromium) (evan-chromium) wrote :

Of course, right after I spam everyone I discover that chromium-browser still crashes with these recent versions of the plugins. Somehow google-chrome as well as a debug build of chrome are fine. Sorry, I retract my previous comments; I'm not sure what's at fault.

Revision history for this message
In , Toshok (toshok) wrote :

The activity on this bug report from the past 4 days is, to say the least, disheartening. I'm not sure what evidence people are using when it comes to statements such as "Sounds like we need to block list the moonlight plugin here." Maybe it was "Sorry, I was going to report a bug in to their tracker about it but it totally slipped my mind." Hardly compelling evidence of guilt.

Given our late arrival to the party (thanks for the heads up, Evan), give us a little bit of time to investigate? We still haven't figured out if it's even our problem.

Revision history for this message
In , Jst (jst) wrote :

Chris, no decisions have been made here, and no one (certainly not me) meant to flat out block anything here w/o figuring out who's in charge of the Moonlight plugin and talking to them and giving them time to react. Flat out blocking w/o an existing update that solves the reason for blocking is our very last resort, we don't go there lightly. I apologize for not being clear about that.

If you read bug 582130, you'll see that one of the steps there is to "notify the authors", which clearly could've been worded better, but the intent there is to figure out who the authors are and let them know we have reason to believe blocking is necessary, and work with them on this issue. Sounds like you're one of the authors, please correct me if I'm wrong on that. And if other people on the Moonlight side need to be involved here, please feel free to cc as many people as necessary on this bug and on bug 582130.

But based on the talk in this bug so far, it does *seem* like old versions (possibly including the current versiono, even) need to be blocked, but if the problem turns out to not be in the Moonlight plugin then we'll naturally investigate further here.

Again, sorry for sending the wrong message here, that was certainly not my intent.

Revision history for this message
In , Toshok (toshok) wrote :

So basically this comes down to a symbol clash between moonlight and IcedTea.

In older moonlights, we have the following:

void
plugin_debug (PluginInstance *plugin)
{
 Surface *surface = plugin->GetSurface ();
...

and in IcedTea they have the following (also in global scope)

int plugin_debug = getenv ("ICEDTEAPLUGIN_DEBUG") != NULL;

the page containing the code for moonlight's plugin_debug is mapped RO, so when the store is attempted in IcedTea, there's a crash.

Revision history for this message
In , Chris Coulson (chrisccoulson) wrote :

Nice catch!

By "older" moonlights, do you know which version no longer has this symbol? It seems that we are shipping versions 2.2 and 2.3 in our supported Ubuntu releases.

I'm quite happy to provide an update for our supported releases which renames that symbol in our moonlight package (and we can update to the latest version in our development release). Would that be an alternative to blacklisting either plugin (assuming other distro's fix their packages too)?

Revision history for this message
In , Chriswian (chriswian) wrote :

Depends on uptake I guess. How long does it generally take for your updates to reach the majority of your users?

Revision history for this message
In , Chris Coulson (chrisccoulson) wrote :

Hmmm, I'm not too sure about that, or whether it's even something we can measure. I'm trying to find out though.

Revision history for this message
In , Toshok (toshok) wrote :

(In reply to comment #40)
> By "older" moonlights, do you know which version no longer has this symbol? It
> seems that we are shipping versions 2.2 and 2.3 in our supported Ubuntu
> releases.

both 2.2 and 2.3 have the symbol. It's been removed (well, c++ namespaced) in master which is where the moonlight 4 stuff will come from. We have a potential fix in git already and should know soon if it actually fixes the problem. I'll update this bug again with revisions when we have confirmation so you can take a look and roll the changes into your packages.

We were going to push a new moonlight 2.x release in the coming days anyway, so this isn't going to cause us too much additional headache.

> I'm quite happy to provide an update for our supported releases which renames
> that symbol in our moonlight package (and we can update to the latest version
> in our development release). Would that be an alternative to blacklisting
> either plugin (assuming other distro's fix their packages too)?

That sound fine to me in the very short term, but we're going to be going through our exported symbols with a fine toothed comb and will likely have something a bit more comprehensive soon.

For people who download via go-mono.com, they will get notified of updates via firefox's extension update mechanism. Those updates should still be visible even if a plugin is blocked, I would assume.

As far as the distro packages are concerned there's no real notification outside of distribution channels that there's an update.

What exactly is the UX for a blocked plugin anyway?

Changed in moon (Ubuntu Maverick):
importance: Undecided → High
status: New → Triaged
Changed in moon (Ubuntu Lucid):
importance: Undecided → High
status: New → Triaged
Changed in moon (Ubuntu Karmic):
importance: Undecided → High
status: New → Triaged
Changed in moon (Ubuntu Natty):
status: Confirmed → Triaged
Changed in moon (Ubuntu Natty):
status: Triaged → Fix Committed
Changed in moon (Ubuntu Natty):
status: Fix Committed → Fix Released
Martin Pitt (pitti)
Changed in moon (Ubuntu Maverick):
status: Triaged → Fix Committed
tags: added: verification-needed
Changed in moon (Ubuntu Lucid):
status: Triaged → Fix Committed
Changed in moon (Ubuntu Karmic):
status: Triaged → Fix Committed
Revision history for this message
In , Jst (jst) wrote :

The UX for blocking depends on what level of blocking we do for a given plugin. There's two levels we can choose from, soft and hard, in the case of a soft block the user will receive a notification about a plugin (or extension) being blocked, saying that there are known issues with the plugin in question but the user can choose to enable the plugin at their own risk. In the case of a hard block, the same thing applies except that there's no option for the user to enable the plugin any more.

The notification that is shown also contains a link to a webpage with more information, but it's a generic page for all plugins. But we can of course add to that page so that there's information specific to whatever plugins are blocked etc.

These notifications comes typically ~10 minutes after firefox was launched, or at a seemingly random point after that (I believe we check once a day) if the users instance of Firefox had already done its initial block list check when the plugin block went into effect.

Revision history for this message
In , Toshok (toshok) wrote :

we've released moonlight 2.4 to address this issue, along with some other bug fixes. it no longer has that symbol (and many, many fewer in general) exported. we're down from ~12k exported symbols to ~3k, if I remember correctly. the moonlight 4 beta packages have been fixed 'the right way" such that we don't export anything at all.

Martin Pitt (pitti)
tags: added: verification-done-maverick
tags: added: verification-done-lucid
Martin Pitt (pitti)
tags: added: verification-done
removed: verification-done-lucid verification-done-maverick verification-needed
Changed in moon (Ubuntu Lucid):
status: Fix Committed → Fix Released
Martin Pitt (pitti)
tags: added: verification-needed
removed: verification-done
Changed in moon (Ubuntu Maverick):
status: Fix Committed → Fix Released
Revision history for this message
In , Karlt (karlt) wrote :

We (Mozilla) should consider loading plugins with RTLD_LOCAL when loading them into the browser process. This looks like a good place to start:
http://hg.mozilla.org/mozilla-central/annotate/4e771e65764a/modules/plugin/base/src/nsPluginsDirUnix.cpp#l306

Revision history for this message
In , Timeless-bemail (timeless-bemail) wrote :

i thought we once had code that did that, but yes, we should.

Revision history for this message
In , Evan Martin (Chromium) (evan-chromium) wrote :

At least on Linux RTLD_LOCAL is the default for dlopen (when RTLD_GLOBAL isn't specified).

I think what went wrong is that moonlight itself dlopen'd a sublibrary with RTLD_GLOBAL, and when icedtea was loaded (with RTLD_LOCAL) it found the now-global symbol from moonlight. (icedtea's symbols themselves weren't exposed to later plugins, but its references to symbols were matched up to the existing global symbols from moonlight.)

Revision history for this message
In , Karlt (karlt) wrote :

OK. Thanks for the explanation, Evan!

Martin Pitt (pitti)
Changed in moon (Ubuntu Karmic):
status: Fix Committed → Won't Fix
Revision history for this message
In , Smooney (smooney) wrote :

There are lots of IcedTea plugin crash signature variations. It's not a top crash, even for Linux only. Removing the top crash keyword.

Changed in chromium:
importance: Undecided → Unknown
status: Invalid → Unknown
Changed in moonlight-plugin-mozilla:
importance: Unknown → Critical
status: Unknown → Confirmed
Changed in moonlight-plugin-mozilla:
status: Confirmed → Won't Fix
Displaying first 40 and last 40 comments. View all 116 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.