Closed Bug 378785 Opened 14 years ago Closed 14 years ago
Crash on launch for nightly builds in Growl code
We're seeing a crash on launch for April 25th nightly. The stack is produced by the nightly doesn't make sense, but the code that's crashing is in Growl. Mossop showed me a stack that made more sense and I was able to track down the problem. I traced it down due to the following console log before the crash: 2007-04-25 19:52:29.496 firefox-bin *** -[NSURL dockDescription]: selector not recognized [self = 0x1a2b5d0] 2007-04-25 19:52:29.496 firefox-bin An uncaught exception was raised 2007-04-25 19:52:29.496 firefox-bin *** -[NSURL dockDescription]: selector not recognized [self = 0x1a2b5d0] 2007-04-25 19:52:29.496 firefox-bin *** Uncaught exception: <NSInvalidArgumentException> *** -[NSURL dockDescription]: selector not recognized [self = 0x1a2b5d0] It's trying to use a method added via a category to NSURL in the file NSURLAdditions.m, but at runtime that method is not showing up. It seems most likely that something is happening during the build process that's preventing this file and/or it symbols from getting built in. The thing is I'm seeing other growl symbols in nm and strings, but not the ones from NSURLAdditions.m. I'm unable to tell if it's a file level or class level problem, because there aren't any symbols or strings in that file that arne't part of the NSURL category. It's all very very strange. I didn't see this on an incremental build with --enable-debug and --disable-optimized, but Mossop is seeing it in his static optimized Non-UB build.
This is a problem with building statically.
Also, there's no crash if Growl isn't installed, which is why it didn't turn the tree red.
LDFLAGS="-Wl,-ObjC" doesn't help. Looks like we need to figure out how to make this always build a dylib.
Seems to work statically for me. This is a dylib for the component, and a dylib for the growl code.
Assignee: nobody → comrade693+bmo
Status: NEW → ASSIGNED
This works for me. Previously my builds would crash on startup, with this it runs fine and I even get a growl notification from completed downloads.
Dynamic component code, static growl code as per bsmedberg's request.
Comment on attachment 263021 [details] [diff] [review] Dynamic Component, Static Growl v1.0 >Index: toolkit/components/alerts/src/mac/Makefile.in > EXTRA_DSO_LDOPTS += \ >- $(MOZ_COMPONENT_LIBS) \ >+ -framework Carbon \ >+ -framework Cocoa \ >+ $(XPCOM_GLUE_LDOPTS) \ nit: use spaces not tabs >Index: toolkit/components/alerts/src/mac/growl/Makefile.in > LDFLAGS += \ > -framework Carbon \ > -framework Foundation \ > -framework AppKit \ > $(NULL) > > EXTRA_DSO_LDOPTS += \ >- $(MOZ_COMPONENT_LIBS) \ >+ $(XPCOM_GLUE_LDOPTS) \ >+ $(NSPR_LIBS) \ > $(NULL) Because we never link this library dynamically (as a .dylib), we shouldn't need any of these LDFLAGS or EXTRA_DSO_LDOPTS. Please remove them unless they are needed for reasons I can't think of.
Attachment #263021 - Flags: review?(benjamin) → review+
Fixes review comments.
Attachment #263021 - Attachment is obsolete: true
Checking in toolkit/components/alerts/Makefile.in; new revision: 1.8; previous revision: 1.7 Checking in toolkit/components/alerts/src/mac/Makefile.in; new revision: 1.2; previous revision: 1.1 Checking in toolkit/components/alerts/src/mac/mozGrowlDelegate.mm; new revision: 1.2; previous revision: 1.1 Checking in toolkit/components/alerts/src/mac/nsAlertsImageLoadListener.h; new revision: 1.2; previous revision: 1.1 Checking in toolkit/components/alerts/src/mac/nsAlertsService.h; new revision: 1.2; previous revision: 1.1 Checking in toolkit/components/alerts/src/mac/nsAlertsService.mm; new revision: 1.2; previous revision: 1.1 Checking in toolkit/components/alerts/src/mac/nsAlertsServiceModule.cpp; initial revision: 1.1 Checking in toolkit/components/alerts/src/mac/growl/Makefile.in; new revision: 1.2; previous revision: 1.1 Checking in toolkit/components/build/Makefile.in; new revision: 1.44; previous revision: 1.43 Checking in toolkit/components/build/nsToolkitCompsModule.cpp; new revision: 1.41; previous revision: 1.40
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
This seems to have broken XULRunner on Mac, per http://tinderbox.mozilla.org/showlog.cgi?log=XULRunner/1177957080.21819.gz
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Not much different from last patch. Now just using TOOL_DIRS when building alerts on the mac to fix XULRunner bustage.
Checking in mozilla/toolkit/components/Makefile.in; new revision: 1.65; previous revision: 1.64 Checking in mozilla/toolkit/components/alerts/Makefile.in; new revision: 1.11; previous revision: 1.10 Checking in mozilla/toolkit/components/alerts/src/mac/Makefile.in; new revision: 1.4; previous revision: 1.3 Checking in mozilla/toolkit/components/alerts/src/mac/mozGrowlDelegate.mm; new revision: 1.4; previous revision: 1.3 Checking in mozilla/toolkit/components/alerts/src/mac/nsAlertsImageLoadListener.h; new revision: 1.4; previous revision: 1.3 Checking in mozilla/toolkit/components/alerts/src/mac/nsAlertsService.h; new revision: 1.4; previous revision: 1.3 Checking in mozilla/toolkit/components/alerts/src/mac/nsAlertsService.mm; new revision: 1.4; previous revision: 1.3 Checking in mozilla/toolkit/components/alerts/src/mac/growl/Makefile.in; new revision: 1.4; previous revision: 1.3 Checking in mozilla/toolkit/components/build/Makefile.in; new revision: 1.47; previous revision: 1.46 Checking in mozilla/toolkit/components/build/nsToolkitCompsModule.cpp; new revision: 1.43; previous revision: 1.42 Checking in mozilla/toolkit/components/alerts/src/mac/nsAlertsServiceModule.cpp; new revision: 1.3; previous revision: 1.2
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.