Closed Bug 503181 Opened 15 years ago Closed 4 years ago

Mac crash reports with Adobe Flash Player should include the version of the Player in use

Categories

(Toolkit :: Crash Reporting, enhancement, P2)

All
macOS
enhancement

Tracking

()

RESOLVED WONTFIX
Tracking Status
blocking2.0 --- -

People

(Reporter: cliss, Unassigned)

References

Details

(Whiteboard: [crashkill][crashkill-metrics])

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.0.11) Gecko/2009060214 Firefox/3.0.11
Build Identifier: 

In order to help Adobe debug crash reports it is important to have the associated version of the Flash Player that crashed with the bug report.

Reproducible: Always

Steps to Reproduce:
See Details.
Actual Results:  
During a crash report no version on Mac is reported for the Flash Player

Expected Results:  
Like with Windows reports Adobe would like the Flash Player version reported.
It seems that there is no version field for a dll under OS X, could be difficult to add....
Status: UNCONFIRMED → NEW
Ever confirmed: true
Easiest fix would be for Adobe to use different file names ;-).

But seriously. It'd help if Charles told his Adobe coworkers to have fewer broken version fields in their plugin :).
(Yes, I'm still smarting from the last one on Linux, but that's a private story.)

timeless-mbp:/ timeless$ perl -e 'use File::Glob ":glob";@plugins = bsd_glob("/Library/Internet Plug-Ins/*plugin/Contents/*plist"); foreach my $plugin (@plugins) { $plugin =~ s/\.plist$//; @args = qw(/usr/bin/defaults read); push @args, $plugin, "CFBundleShortVersionString"; $plugin =~ s/^.{27}//; $plugin =~ s{/Contents/}{ }; print "$plugin: "; system(@args);}' 2>&1 |grep -v 'defaults\['|grep -v 'domain/default'
Flash Player.plugin Info: 10.0.22.87
Flash Player.plugin version: 9.0.151
Flip4Mac WMV Plugin.plugin Info: 2.2.2.3 
Flip4Mac WMV Plugin.webplugin Info: 2.2.2.3 
googletalkbrowserplugin.plugin Info: 1.0.10.1159
Quartz Composer.webplugin Info: 1.1
Quartz Composer.webplugin version: 1.1
QuickTime Plugin.plugin Info: 7.6.2
QuickTime Plugin.plugin version: 7.6.2
QuickTime Plugin.webplugin Info: 7.6.2
QuickTime Plugin.webplugin version: 7.6.2
VerifiedDownloadPlugin.plugin Info: 1.1
VerifiedDownloadPlugin.plugin version: 1.1

Charles: could you please ask someone to fix Flash Player's version.plist to not say 9.0.151 ? -- thanks :)

It should be possible for us to do something programmatically equivalent to the above and use it to provide version info (note that we should include both version and Info just to deal with the screwballs out there).

FWIW, a more generic version also seems to work:
perl -e 'use File::Glob ":glob";@plugins = bsd_glob("/Library/*/*/Contents/*plist"); foreach my $plugin (@plugins) { $plugin =~ s/\.plist$//; @args = qw(/usr/bin/defaults read); push @args, $plugin, "CFBundleShortVersionString"; $plugin =~ s{/Contents/}{ }; print "$plugin: "; system(@args);}' 2>&1 |grep -v 'defaults\['|grep -v 'domain/default'
Severity: major → enhancement
Wow that shouldn't be.  

When I look directly into the Plist in the package contents of the build you mention I don't see any reference to plugin version 9.0.151. Can you zip up the plugin you have.
Attached file Info.plist
The full plugin is to big to attach.

Info.plist has the correct version for me.
Attached file version.plist
version.plist has an old (incorrect) version.
Attachment #387831 - Attachment mime type: application/octet-stream → text/plain
Thanks.  We removed version.plist from the player and looks like you upgraded from 9 to 10 and it stayed behind.  If you deleted the plugin and reinstalled you would notice this goes away.  We will be adding this back in the future.
There are a couple of issues here:

1) The Breakpad code to include "library versions" on Mac OS X (breakpad svn r291, http://code.google.com/p/google-breakpad/source/detail?r=291) doesn't seem to be "hooked up" in the Mozilla Crash Reporter (since mozilla-1.9.1 and mozilla-central both appear to have breakpad svn r303).

I say this (and speculatively point at the Mozilla Crash Reporter) because Firefox crash reports on Mac OS X don't seem to send any version numbers, whereas Camino reports, which use the native Breakpad.framework client, do; compare the "Modules" tab from 
http://crash-stats.mozilla.com/report/index/699bb110-5373-4b1d-aaec-393352090724
with
http://crash-stats.mozilla.com/report/index/f44a7974-1ef3-4d87-834f-7880f2090729

2) As Ted has mentioned in another bug, Breakpad's idea of a version number isn't incredibly useful on Mac OS X.  It's OK for some system libraries, e.g., AppKit or WebKit, that encode the UNIX-style version numbers *and* then mirror those numbers into the CFBundleVersion, where they're publicly known and used as references in real life. (Ironically, these are the libraries/modules where it's least useful for us to have this info, since they don't typically change independent of the OS.)

For everything else, the Breakpad definition of "version number" is pretty useless, and I filed http://code.google.com/p/google-breakpad/issues/detail?id=321 about that; it's frustrating for everyone not to have useful version numbers.  If the Breakpad issue gets fixed using the heuristic I proposed (fallback to Info.plist data for anything that's blank or 0.0.0.0), we'd be in better shape.

2a) Note, however, that Flash 10.0.32.18 currently reports its CFBundleVersion as "1.0.4f18472".

I'm not sure if that's an interesting value to Adobe internally, but *if* Breakpad were to fix issue 321 *and* use CFBundleVersion first, Flash's CFBundleVersion wouldn't result in a number that would be immediately useful to anyone outside of Adobe (say, Mozilla devs/QA looking through crash reports and being able to say "oh, that's a really old Flash").  

I don't know what the best primary fallback value is, though (depending on the type of code, one type of CFBundle* number is more useful than another), or if anyone will ever code a fix for the Breakpad issue I filed.

However, if Mozilla were to fix item 1 above, Adobe could perhaps(?) work around 2 by encoding the Flash version into the plug-in's binary when linking. I don't know how easy that is, or what it might break--it's all over my head--I just know the Breakpad.framework that Camino uses does it.
Could Breakpad use the same source of version numbers that Tools > Addons > Plugins uses?  (Could be computed only when breakpad is triggered, or well before, e.g. when the plugin is loaded.)
(In reply to comment #7)
> There are a couple of issues here:
> 
> 1) The Breakpad code to include "library versions" on Mac OS X (breakpad svn
> r291, http://code.google.com/p/google-breakpad/source/detail?r=291) doesn't
> seem to be "hooked up" in the Mozilla Crash Reporter (since mozilla-1.9.1 and
> mozilla-central both appear to have breakpad svn r303).

I just looked at this code, and this is because the Mac exception handler code has two paths: in-process and out-of-process (referred to as "dynamic images" in the Breakpad codebase). We are using the in-process exception handler, but that version number code is only implemented in the out-of-process case:
http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/google-breakpad/src/client/mac/handler/minidump_generator.cc#682
Josh: Can you work on this?
Assignee: nobody → joshmoz
(In reply to comment #8)
> Could Breakpad use the same source of version numbers that Tools > Addons >
> Plugins uses?  (Could be computed only when breakpad is triggered, or well
> before, e.g. when the plugin is loaded.)

That's kind of difficult, because AIUI, that involves asking the plugin for its version. That's not something we can do in the exception handler, and doing it ahead of time means that Breakpad would have to know how to call plugins, which seems difficult.
Whiteboard: [crashkill]
Whiteboard: [crashkill] → [crashkill][crashkill-metrics]
Based on https://wiki.mozilla.org/CrashKill/Mac_Flash_Identifiers I bet this can be done server-side.
Flags: blocking1.9.2+
Priority: -- → P2
The Flash binary doesn't have the type of version data we get on Windows. We'd have to dig around the framework/plist in order to get a version, which doesn't seem like something we want to do in the breakpad handler.

Based on what I know now I think a server-side solution is probably best, or we can simply continue to do a manual analysis. Manual analysis takes 1-2 minutes per Flash crash, which might be easy enough that we don't need a more technical solution.

A server-side solution should probably just attempt to match module checksums to a known version list for modules that don't have module data.
Deciding and executing on a strategy here should be a high priority but given that we can get this data pretty easily right now I don't see why this needs to block.
Agreed, not blocking: we can map it on our side, and there's a bug open to do that on the socorro component somewhere.
Flags: blocking1.9.2+ → blocking1.9.2-
Depends on: 525098
Bug 525098.
Assignee: joshmoz → nobody
The latest Flash Player 10.1 beta and next security update will have a new Symbol you can pluck from.  Its called FlashPlayer_[Version]  When read it should read something like FlashPlayer_10_1_51_45
Its a simple solution until you can read the actual resource.  Apple has the ability to do this somehow so I figure Firefox can as well.
blocking2.0: --- → ?
My patch in bug 412633 will fix this; crash reports will be annotated with a list of plugins (including version).
Depends on: 412633
Shaver and josh's reasoning still holds, not blocking but nice to see it happen anyway
blocking2.0: ? → -

Flash will be removed in version 85. Closing all related bugs.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: