diff options
author | mark@chromium.org <mark@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-09-03 14:14:09 +0000 |
---|---|---|
committer | mark@chromium.org <mark@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-09-03 14:14:09 +0000 |
commit | 7e2668790ed8fd3e0373b0b365137b32923ec9da (patch) | |
tree | 76b3848233cab71163482953ccefed17c525eda9 /base | |
parent | 68b6c741768fbe6b74517948a13b414f7fff4741 (diff) | |
download | chromium_src-7e2668790ed8fd3e0373b0b365137b32923ec9da.zip chromium_src-7e2668790ed8fd3e0373b0b365137b32923ec9da.tar.gz chromium_src-7e2668790ed8fd3e0373b0b365137b32923ec9da.tar.bz2 |
Check the right Info.plist to determine whether the app is the browser or a
background helper.
This fixes the Breakpad about:crash problem, but not directly. I'm not
exactly sure of the failure mechanism here. It's likely that doing this call
properly here caches the Info.plist dictionary, and that something in Breakpad
crashes when that's not done. Without this fix, we're seeing a double fault,
with the second exception occurring in the renderer while it is processing
the crash. Likely because of the use of fork && execv instead of posix_spawn
to launch the renderer, the second exception is delivered to the browser
process. The browser's Breakpad instance recognizes that the exception is not
its own, but attempts to act on it in part anyway. There may be a Breakpad
bug here, I'll investigate more tomorrow.
BUG=20371
TEST=In a Breakpad-enabled build, about:crash should bring up a sad tab and
not crash the browser process
Review URL: http://codereview.chromium.org/194007
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@25311 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'base')
-rw-r--r-- | base/mac_util.mm | 7 |
1 files changed, 5 insertions, 2 deletions
diff --git a/base/mac_util.mm b/base/mac_util.mm index dcfb6470..1fce49a 100644 --- a/base/mac_util.mm +++ b/base/mac_util.mm @@ -44,8 +44,11 @@ bool AmIBundled() { } bool IsBackgroundOnlyProcess() { - NSBundle* main_bundle = MainAppBundle(); - NSDictionary* info_dictionary = [main_bundle infoDictionary]; + // This function really does want to examine NSBundle's idea of the main + // bundle dictionary, and not the overriden MainAppBundle. It needs to look + // at the actual running .app's Info.plist to access its LSUIElement + // property. + NSDictionary* info_dictionary = [[NSBundle mainBundle] infoDictionary]; return [[info_dictionary objectForKey:@"LSUIElement"] boolValue] != NO; } |