582130 - Crash [@ IcedTeaPlugin.so@0x873c ][@ IcedTeaPlugin.so@0x866c ][@ IcedTeaPlugin.so@0x7cfc ][@ IcedTeaPlugin.so@0x85fc ] caused by symbol name clash with libmoon.so

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect)

Description

[fayaboom]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.2.6) Gecko/20100626 SUSE/3.6.6-1.2 Firefox/3.6.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.11) Gecko/20100714 SUSE/3.0.6 Thunderbird/3.0.6

Thunderbird crash each time I make it open an email. That happens with any of my email boxes. It crash too when I try to open the extension manager.
Started with the terminal, it gives that :
Attempting to load the system libmoon 
/usr/bin/thunderbird: line 130: 13590 Erreur de segmentation  $MOZ_PROGRAM "$@"
Sometimes, the error number can be different.

Reproducible: Always

Steps to Reproduce:
1.Start thunderbird
2.Make it download some new emails
3.jsut click on any one to read it
Actual Results:  
Crash, the thunderbird window disappear and the PID too.

Expected Results:  
Thunderbird might show the email

Comment 1

[Ludovic Hirlimann [:Usul]]

Hello,

can you follow the instructions at http://en.opensuse.org/openSUSE:Bugreport_application_crashed and provide us with a stack trace ?

Comment 2

[fayaboom]

Thank for your fast reply.

I did a stack trace and send the log via email for you because of its weight of 8.4Mo.

Comment 3

[Ludovic Hirlimann [:Usul]]

(In reply to comment #2)
> Thank for your fast reply.
> 
> I did a stack trace and send the log via email for you because of its weight of
> 8.4Mo.

I didn't receive it yet :-(

Comment 4

[fayaboom]

Attachment: required Strace log file

Comment 5

[timeless]

jar:https://bug582130.bugzilla.mozilla.org/attachment.cgi?id=460599!/strace.log

14577 1280245825.045538 access("/usr/lib/jvm/java-1.6.0-openjdk-1.6.0/jre/lib/i386/IcedTeaNPPlugin.so", F_OK) = 0
14577 1280245825.046799 open("/usr/lib/jvm/java-1.6.0-openjdk-1.6.0/jre/lib/i386/IcedTeaNPPlugin.so", O_RDONLY) = 24
14577 1280245825.047161 read(24, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0P\217\0\0004\0\0\0"..., 512) = 512
14577 1280245825.047365 fstat64(24, {st_mode=S_IFREG|0755, st_size=207412, ...}) = 0
14577 1280245825.047679 mmap2(NULL, 210540, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 24, 0) = 0xa63ca000
14577 1280245825.047996 fadvise64(24, 0, 210540, POSIX_FADV_WILLNEED) = 0
14577 1280245825.048285 mmap2(0xa63fc000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 24, 0x31) = 0xa63fc000
14577 1280245825.048800 close(24)       = 0
14577 1280245825.056566 mprotect(0xa63fc000, 4096, PROT_READ) = 0
14577 1280245825.059094 --- SIGSEGV (Segmentation fault) @ 0 (0) ---

This isn't a stack trace, it's a system call trace. it's 99.99% useless.

Comment 6

[fayaboom]

This is the advised log in this webpage 'http://en.opensuse.org/openSUSE:Bugreport_application_crashed' with strace. I was not supposed to know this was not a system call trace.
Anyway !!!
When I do it with gdb what I don't know more its kind of backtrace it gives me:


gdb /usr/lib/thunderbird/thunderbird-bin
GNU gdb (GDB) SUSE (7.1-3.12)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i586-suse-linux".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/lib/thunderbird/thunderbird-bin...
warning: the debug information found in "/usr/lib/debug//usr/lib/thunderbird/thunderbird-bin.debug" does not match "/usr/lib/thunderbird/thunderbird-bin" (CRC mismatch).


warning: the debug information found in "/usr/lib/debug/usr/lib/thunderbird/thunderbird-bin.debug" does not match "/usr/lib/thunderbird/thunderbird-bin" (CRC mismatch).

Missing separate debuginfo for /usr/lib/thunderbird/thunderbird-bin
Try: zypper install -C "debuginfo(build-id)=87e33fa8b41e194344361b46417d8aecef097c6f"
(no debugging symbols found)...done.

For information, I installed both debuginfo and debugsource thunderbird packages.

After, it has that : 


(gdb) run
Starting program: /usr/lib/thunderbird/thunderbird-bin 
Missing separate debuginfo for /lib/ld-linux.so.2
Try: zypper install -C "debuginfo(build-id)=22e2b3718e8271a0d899156a796b0a90bc4dc391"
/usr/lib/thunderbird/thunderbird-bin: error while loading shared libraries: libmozjs.so: cannot open shared object file: No such file or directory

Program exited with code 0177.

And zypper install... gives an error

Comment 7

[Wolfgang Rosenauer [:wolfiR]]

Here is another desription which is more mozilla specific:
http://old-en.opensuse.org/Bugs:mozilla

LD_LIBRARY_PATH=/usr/lib/thunderbird gdb /usr/lib/thunderbird/thunderbird-bin

should help.

If you would be interested to use and try Thunderbird 3.1.1 I could give you advice how to do it. That one would also include the automatic crashreporter which would make this manual process pretty much obsolete.

Comment 8

[fayaboom]

Ok, I tried it with 

LD_LIBRARY_PATH=/usr/lib/thunderbird gdb /usr/lib/thunderbird/thunderbird-bin

It got freezed and the output said :

thunderbird -d gdb
gdb /usr/lib/thunderbird/thunderbird-bin -x /tmp/mozargs.Z962Tl
GNU gdb (GDB) SUSE (7.1-3.12)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i586-suse-linux".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/lib/thunderbird/thunderbird-bin...
warning: the debug information found in "/usr/lib/debug//usr/lib/thunderbird/thunderbird-bin.debug" does not match "/usr/lib/thunderbird/thunderbird-bin" (CRC mismatch).

warning: the debug information found in "/usr/lib/debug/usr/lib/thunderbird/libmozjs.so.debug" does not match "/usr/lib/thunderbird/libmozjs.so" (CRC mismatch).

Missing separate debuginfo for /usr/lib/thunderbird/libmozjs.so
Try: zypper install -C "debuginfo(build-id)=c4742b9f4e5a48e7e001efff73dd3964f549e245"
warning: the debug information found in "/usr/lib/debug//usr/lib/thunderbird/libxpcom.so.debug" does not match "/usr/lib/thunderbird/libxpcom.so" (CRC mismatch).

Missing separate debuginfo for /lib/libuuid.so.1
Try: zypper install -C "debuginfo(build-id)=6ff9c8838bc92ab347368af9073209bac1ef2966"

warning: the debug information found in "/usr/lib/debug//usr/lib/thunderbird/components/libmozgnome.so.debug" does not match "/usr/lib/thunderbird/components/libmozgnome.so" (CRC mismatch).

warning: the debug information found in "/usr/lib/debug/usr/lib/thunderbird/components/libmozgnome.so.debug" does not match "/usr/lib/thunderbird/components/libmozgnome.so" (CRC mismatch).
...
*** nss-shared-helper: Shared database disabled (set NSS_USE_SHARED_DB to enable).
...
[New Thread 0xb35ffb70 (LWP 9515)]
[New Thread 0xb20ffb70 (LWP 9516)]
[New Thread 0xb0efeb70 (LWP 9517)]
[New Thread 0xb419fb70 (LWP 9518)]
[New Thread 0xa74ffb70 (LWP 9521)]
...
Detaching after fork from child process 9566.
Missing separate debuginfo for /usr/lib/browser-plugins/npwrapper.libmoonloader.so
...
Missing separate debuginfo for /usr/lib/jvm/java-1.6.0-openjdk-1.6.0/jre/lib/i386/IcedTeaNPPlugin.so
...
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

Comment 9

[fayaboom]

With LD_LIBRARY_PATH=/usr/lib/thunderbird gdb /usr/lib/thunderbird/thunderbird-bin

I got : 
GNU gdb (GDB) SUSE (7.1-3.12)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i586-suse-linux".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/lib/thunderbird/thunderbird-bin...
warning: the debug information found in "/usr/lib/debug//usr/lib/thunderbird/thunderbird-bin.debug" does not match "/usr/lib/thunderbird/thunderbird-bin" (CRC mismatch).


warning: the debug information found in "/usr/lib/debug/usr/lib/thunderbird/thunderbird-bin.debug" does not match "/usr/lib/thunderbird/thunderbird-bin" (CRC mismatch).
...
[New Thread 0xb419fb70 (LWP 10029)]
[Thread 0xb419fb70 (LWP 10029) exited]
[New Thread 0xb419fb70 (LWP 10030)]
[New Thread 0xb35ffb70 (LWP 10031)]
Missing separate debuginfo for /usr/lib/libXss.so.1
Try: zypper install -C "debuginfo(build-id)=e064c691a0ea92dee6d202a5de52643fd8bc77cd"
[New Thread 0xb2bffb70 (LWP 10033)]
[New Thread 0xb1fffb70 (LWP 10034)]
[New Thread 0xb17feb70 (LWP 10035)]
[Thread 0xb419fb70 (LWP 10030) exited]
...
[Thread 0xb1fffb70 (LWP 10034) exited]
[Thread 0xb17feb70 (LWP 10035) exited]
...
[New Thread 0xb419fb70 (LWP 10037)]
[New Thread 0xb1fffb70 (LWP 10038)]
[New Thread 0xb17feb70 (LWP 10039)]
[New Thread 0xa7effb70 (LWP 10040)]
[New Thread 0xa73ffb70 (LWP 10044)]
...
[Thread 0xb2bffb70 (LWP 10033) exited]
[Thread 0xb419fb70 (LWP 10037) exited]
[Thread 0xb1fffb70 (LWP 10038) exited]
[Thread 0xa7effb70 (LWP 10040) exited]
[Thread 0xb5bffb70 (LWP 10026) exited]
[Thread 0xb17feb70 (LWP 10039) exited]
[Thread 0xb35ffb70 (LWP 10031) exited]
[Thread 0xb4b4fb70 (LWP 10028) exited]
[Thread 0xb53feb70 (LWP 10027) exited]

Program exited normally.
(gdb)

Comment 10

[fayaboom]

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

Comment 11

[fayaboom]

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

Comment 12

[timeless]

(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).

Comment 13

[Wolfgang Rosenauer [:wolfiR]]

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.

Comment 14

[fayaboom]

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

;-)

Comment 15

[timeless]

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

Comment 16

[Wayne Mery (:wsmwk)]

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

that's pretty amazing for a linux-only crash

Comment 17

[Daniel Veditz [:dveditz]]

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

Comment 18

[Daniel Veditz [:dveditz]]

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.

Comment 19

[fayaboom]

Howto reopen it thus ?

Comment 20

[Mark Banner (:standard8)]

(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.

Comment 21

[fayaboom]

Attachment: Another segmentation error from Thunderbird 3.06 under OpenSUSE 11.3

Comment 22

[Chris Coulson]

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....

Comment 23

[Scoobidiver (away)]

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

Comment 25

[timeless]

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.

Comment 26

[timeless]

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.

Comment 27

[Benjamin Smedberg]

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.

Comment 28

[Chris Coulson]

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)

Comment 29

[Chris Coulson]

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

Comment 30

[Chris Coulson]

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

Comment 31

[timeless]

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",

Comment 32

[timeless]

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

Comment 33

[Sheila Mooney]

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

Comment 34

[Johnny Stenback (:jst)]

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.

Comment 35

[Evan Martin (Chromium)]

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.

Comment 36

[Evan Martin (Chromium)]

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.

Comment 37

[Chris Toshok]

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.

Comment 38

[Johnny Stenback (:jst)]

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.

Comment 39

[Chris Toshok]

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.

Comment 40

[Chris Coulson]

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)?

Comment 41

[LegNeato]

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

Comment 42

[Chris Coulson]

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

Comment 43

[Chris Toshok]

(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?

Comment 44

[Johnny Stenback (:jst)]

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.

Comment 45

[Chris Toshok]

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.

Comment 46

[Karl Tomlinson (:karlt)]

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

Comment 47

[timeless]

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

Comment 48

[Evan Martin (Chromium)]

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.)

Comment 49

[Karl Tomlinson (:karlt)]

OK.  Thanks for the explanation, Evan!

Comment 50

[Sheila Mooney]

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

Comment 51

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

I'm marking this bug as WONTFIX per bug #1269807,
what's more these bug crashlog signatures didn't appear from a long time (over half year)

For more information see - https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/