Closed
Bug 917753
Opened 11 years ago
Closed 11 years ago
make clean doesn't remove xpidl files
Categories
(Firefox Build System :: General, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla27
People
(Reporter: gaston, Assigned: gps)
References
Details
Attachments
(1 file)
1.60 KB,
patch
|
glandium
:
review+
|
Details | Diff | Splinter Review |
Since a little while my openbsd clobber builds randomly fail with missing nsISupports.h headers in the path, so that might be a dependency problem ? Usually removing the objdir fixes it but that's not a proper fix. Dunno what's supposed to generate nsISupports.h ?
eg++ -o nsReadableUtils.o -c -fvisibility=hidden -DMOZ_GLUE_IN_PROGRAM -DMOZILLA_INTERNAL_API -DNO_NSPR_10_SUPPORT -DIMPL_LIBXUL -I/home/buildslave/mozilla-central-sparc64/build/xpcom/string/src -I. -I../../../dist/include -I/data/obj/buildslave/m-c/dist/include/nspr -I/data/obj/buildslave/m-c/dist/include/nss -fPIC -I/usr/X11R6/include -DMOZILLA_CLIENT -include ../../../mozilla-config.h -MD -MP -MF .deps/nsReadableUtils.o.pp -I/usr/X11R6/include -Wall -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Wtype-limits -Wempty-body -Wsign-compare -Wno-invalid-offsetof -fno-exceptions -fno-strict-aliasing -fno-rtti -fno-exceptions -fno-math-errno -std=gnu++0x -pthread -pipe -DNDEBUG -DTRIMMED -g -O -fomit-frame-pointer /home/buildslave/mozilla-central-sparc64/build/xpcom/string/src/nsReadableUtils.cpp
nsString.o
In file included from ../../../dist/include/nsCycleCollectionNoteChild.h:12:0,
from ../../../dist/include/nsTArray.h:18,
from /home/buildslave/mozilla-central-sparc64/build/xpcom/string/src/nsReadableUtils.cpp:10:
../../../dist/include/nsCycleCollectionTraversalCallback.h:9:25: fatal error: nsISupports.h: No such file or directory
compilation terminated.
This is happening regardless of arch & compiler used.
Reporter | ||
Comment 1•11 years ago
|
||
http://buildbot.rhaalovely.net/builders/mozilla-central-amd64/builds/874 is an occurence from some days ago.. i think it was one of the first hit.
http://buildbot.rhaalovely.net/builders/mozilla-central-sparc64/builds/554 is another from yesterday.
It also affects c-c, see http://buildbot.rhaalovely.net/builders/comm-central-amd64/builds/855
Sometimes, it's on a missing nsIAtom.h:
eg++ -o nsSubstring.o -c -I../../../dist/stl_wrappers -I../../../dist/system_wrappers -include /home/buildslave/comm-central-i386/build/mozilla/config/gcc_hidden.h -DMOZ_GLUE_IN_PROGRAM -DMOZILLA_INTERNAL_API -DNO_NSPR_10_SUPPORT -DIMPL_LIBXUL -I/home/buildslave/comm-central-i386/build/mozilla/xpcom/string/src -I. -I../../../dist/include -I/var/buildslave/comm-central-i386/build/obj-i386-unknown-openbsd5.4/mozilla/dist/include/nspr -I/var/buildslave/comm-central-i386/build/obj-i386-unknown-openbsd5.4/mozilla/dist/include/nss -fPIC -I/usr/X11R6/include -DMOZILLA_CLIENT -include ../../../mozilla-config.h -MD -MP -MF .deps/nsSubstring.o.pp -I/usr/X11R6/include -Wall -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Wtype-limits -Wempty-body -Wsign-compare -Wno-invalid-offsetof -Wcast-align -fno-exceptions -fno-strict-aliasing -fno-rtti -fno-exceptions -fno-math-errno -std=gnu++0x -pthread -pipe -DNDEBUG -DTRIMMED -O -fomit-frame-pointer /home/buildslave/comm-central-i386/build/mozilla/xpcom/string/src/nsSubstring.cpp
In file included from /home/buildslave/comm-central-i386/build/mozilla/xpcom/string/src/nsSubstring.cpp:25:0:
../../../dist/include/nsStaticAtom.h:9:21: fatal error: nsIAtom.h: No such file or directory
compilation terminated.
(from http://buildbot.rhaalovely.net/builders/comm-central-i386/builds/407)
Reporter | ||
Comment 2•11 years ago
|
||
http://buildbot.rhaalovely.net/builders/mozilla-central-amd64/builds/880 is also an occurence of a missing nsIAtom.h
Reporter | ||
Updated•11 years ago
|
Summary: Random build failure with missing nsISupports.h header → Random build failure with missing nsISupports.h or nsIAtom.h header
Reporter | ||
Comment 3•11 years ago
|
||
More failures... removed the objdirs this time. The usual process is hg pull -u, gmake -f client.mk, gmake package, gmake clean. In case nsI* are sometimes not generated (missing dep ?)
http://buildbot.rhaalovely.net/builders/mozilla-central-sparc64/builds/556
http://buildbot.rhaalovely.net/builders/mozilla-central-amd64/builds/886
http://buildbot.rhaalovely.net/builders/comm-central-amd64/builds/861
Reporter | ||
Comment 4•11 years ago
|
||
Sadly, this also affects aurora:
http://buildbot.rhaalovely.net/builders/mozilla-aurora-amd64/builds/871
ccing some hopefully helpful folks for hints on the possible cause of this :)
Comment 5•11 years ago
|
||
Maybe Ehsan has a better idea of what might have regressed it. It sounds like something the recent flurry of work on #include elimination could have broken.
Flags: needinfo?(ehsan)
Comment 7•11 years ago
|
||
Yeah this is almost definitely a race condition in the build system.
Component: XPCOM → Build Config
Flags: needinfo?(ehsan)
Comment 8•11 years ago
|
||
(In reply to comment #5)
> Maybe Ehsan has a better idea of what might have regressed it. It sounds like
> something the recent flurry of work on #include elimination could have broken.
Note that could not have possibly happened, since this bug seems to be about the files not being there on the filesystem, it seems.
Reporter | ||
Comment 9•11 years ago
|
||
(In reply to :Ehsan Akhgari (needinfo? me!) from comment #8)
> (In reply to comment #5)
> > Maybe Ehsan has a better idea of what might have regressed it. It sounds like
> > something the recent flurry of work on #include elimination could have broken.
>
> Note that could not have possibly happened, since this bug seems to be about
> the files not being there on the filesystem, it seems.
Yeah, when the failure shows up, the offending file is not in the objdir at all, ie not generated.
Assignee | ||
Comment 10•11 years ago
|
||
You are seeing this on current mozilla-central? I could understand nsISupports.h being out of date in dist/includes, but for it to not be present at all is, uh, very surprising.
What do you see in objdir/config/makefiles/xpidl?
Flags: needinfo?(gps)
Reporter | ||
Comment 11•11 years ago
|
||
My other builders are failing hard atm because of #919111 but for aurora from yesterday:
http://buildbot.rhaalovely.net/builders/mozilla-aurora-amd64/builds/873/steps/build/logs/stdio
This is what i have there:
/usr/obj/buildslave-m-a/config/makefiles/xpidl/Makefile
/usr/obj/buildslave-m-a/config/makefiles/xpidl/xpt:
WorkerTest.xpt dom_base.xpt dom_svg.xpt intl.xpt necko_websocket.xpt update.xpt
accessibility.xpt dom_camera.xpt dom_system.xpt jar.xpt necko_wyciwyg.xpt uriloader.xpt
alerts.xpt dom_canvas.xpt dom_telephony.xpt jsdebugger.xpt parentalcontrols.xpt url-classifier.xpt
appshell.xpt dom_contacts.xpt dom_time.xpt jsdownloads.xpt pipboot.xpt urlformatter.xpt
appstartup.xpt dom_core.xpt dom_traversal.xpt jsdservice.xpt pipnss.xpt webBrowser_core.xpt
autocomplete.xpt dom_css.xpt dom_webspeechrecognition.xpt jsinspector.xpt pippki.xpt webbrowserpersist.xpt
autoconfig.xpt dom_devicestorage.xpt dom_webspeechsynth.xpt layout_base.xpt places.xpt widget.xpt
browser-feeds.xpt dom_events.xpt dom_xbl.xpt layout_printing.xpt plugin.xpt windowds.xpt
browsercompsbase.xpt dom_file.xpt dom_xpath.xpt layout_xul.xpt pref.xpt windowwatcher.xpt
caps.xpt dom_gamepad.xpt dom_xul.xpt layout_xul_tree.xpt prefetch.xpt xpcom_base.xpt
chrome.xpt dom_geolocation.xpt downloads.xpt locale.xpt profile.xpt xpcom_components.xpt
commandhandler.xpt dom_html.xpt editor.xpt loginmgr.xpt rdf.xpt xpcom_ds.xpt
commandlines.xpt dom_indexeddb.xpt embed_base.xpt lwbrk.xpt satchel.xpt xpcom_io.xpt
composer.xpt dom_json.xpt extensions.xpt migration.xpt saxparser.xpt xpcom_system.xpt
content_base.xpt dom_media.xpt exthandler.xpt mimetype.xpt services-crypto-component.xpt xpcom_threads.xpt
content_canvas.xpt dom_messages.xpt exthelper.xpt mozfind.xpt sessionstore.xpt xpcom_xpti.xpt
content_events.xpt dom_mobilemessage.xpt fastfind.xpt necko.xpt shellservice.xpt xpcomsample.xpt
content_html.xpt dom_network.xpt feeds.xpt necko_about.xpt shistory.xpt xpconnect.xpt
content_htmldoc.xpt dom_notification.xpt filepicker.xpt necko_cache.xpt spellchecker.xpt xpctest.xpt
content_xslt.xpt dom_offline.xpt find.xpt necko_cookie.xpt startupcache.xpt xul.xpt
cookie.xpt dom_permissionsettings.xpt fuel.xpt necko_dns.xpt storage.xpt xulapp.xpt
directory.xpt dom_power.xpt gfx.xpt necko_file.xpt telemetry.xpt xuldoc.xpt
diskspacewatcher.xpt dom_quota.xpt hal.xpt necko_ftp.xpt test_necko.xpt xultmpl.xpt
docshell.xpt dom_range.xpt html5.xpt necko_http.xpt toolkitprofile.xpt zipwriter.xpt
dom.xpt dom_settings.xpt htmlparser.xpt necko_ipc.xpt toolkitremote.xpt
dom_activities.xpt dom_sidebar.xpt identity.xpt necko_res.xpt txmgr.xpt
dom_alarm.xpt dom_smil.xpt imgicon.xpt necko_socket.xpt txtsvc.xpt
dom_apps.xpt dom_storage.xpt imglib2.xpt necko_strconv.xpt uconv.xpt
dom_audiochannel.xpt dom_stylesheets.xpt inspector.xpt necko_viewsource.xpt unicharutil.xpt
And the list of nsI* headers in dist/include:
[21:18] dawn:/usr/obj/buildslave-m-a/dist/include/ $ls nsI*
nsIAccessibilityService.h@ nsIDTD.h@ nsIJSNativeInitializer.h@ nsIPrivateTextEvent.h@ nsIStyleRuleProcessor.h@
nsIAllocator.h@ nsIDateTimeFormat.h@ nsILanguageAtomService.h@ nsIPrivateTextRange.h@ nsIStyleSheet.h@
nsIAnonymousContentCreator.h@ nsIDeviceContextSpec.h@ nsILayoutDebugger.h@ nsIRDFContentSink.h@ nsIStyleSheetLinkingElement.h@
nsIAppStartupNotifier.h@ nsIDocument.h@ nsILayoutHistoryState.h@ nsIRadioGroupContainer.h@ nsISupportsBase.h@
nsIAttribute.h@ nsIDocumentInlines.h@ nsILineBreaker.h@ nsIRadioVisitor.h@ nsISupportsImpl.h@
nsIAudioChannelAgent.h nsIDocumentObserver.h@ nsILineIterator.h@ nsIReflowCallback.h@ nsISupportsObsolete.h@
nsICSSDeclaration.h@ nsIDocumentTransformer.h@ nsILinkHandler.h@ nsIRollupListener.h@ nsISupportsUtils.h@
nsICSSLoaderObserver.h@ nsIFileStorage.h@ nsIListControlFrame.h@ nsISMILAttr.h@ nsITableCellLayout.h@
nsICSSPseudoComparator.h@ nsIForm.h@ nsILocalStore.h@ nsISMILType.h@ nsITextControlElement.h@
nsICSSRuleList.h@ nsIFormControl.h@ nsIMutationObserver.h@ nsIScriptContext.h@ nsITextControlFrame.h@
nsICSSStyleRuleDOMWrapper.h@ nsIFormControlFrame.h@ nsINIParser.h@ nsIScriptElement.h@ nsITextService.h@
nsICachedFileDescriptorListener.h@ nsIFormProcessor.h@ nsINameSpaceManager.h@ nsIScriptExternalNameSet.h@ nsITextServicesDocument.h@
nsICanvasElementExternal.h@ nsIFragmentContentSink.h@ nsINativeKeyBindings.h@ nsIScriptGlobalObject.h@ nsITheme.h@
nsICanvasRenderingContextInternal.h@ nsIFrame.h@ nsINode.h@ nsIScriptGlobalObjectOwner.h@ nsITokenizer.h@
nsICaseConversion.h@ nsIFrameTraversal.h@ nsINodeInfo.h@ nsIScriptNameSpaceManager.h@ nsIUGenCategory.h@
nsICharsetDetectionObserver.h@ nsIFrameUtil.h@ nsINodeList.h@ nsIScriptObjectPrincipal.h@ nsIUnicodeDecoder.h@
nsICharsetDetector.h@ nsIGlobalObject.h@ nsIOS2Locale.h@ nsIScriptTimeoutHandler.h@ nsIUnicodeEncoder.h@
nsIClassInfoImpl.h@ nsIGridPart.h@ nsIObjectFrame.h@ nsIScrollPositionListener.h@ nsIWeakReferenceUtils.h@
nsIComboboxControlFrame.h@ nsIHTMLCollection.h@ nsIOfflineStorage.h@ nsIScrollableFrame.h@ nsIWebShellServices.h@
nsIConstraintValidation.h@ nsIHTMLContentSink.h@ nsIPageSequenceFrame.h@ nsIScrollbarMediator.h@ nsIWidget.h@
nsIContent.h@ nsIHTMLDocument.h@ nsIParser.h@ nsIScrollbarOwner.h@ nsIWidgetListener.h@
nsIContentIterator.h@ nsIID.h@ nsIParserService.h@ nsISelectControlFrame.h@ nsIWordBreaker.h@
nsIContentSerializer.h@ nsIIPCSerializableInputStream.h@ nsIPercentHeightObserver.h@ nsISizeOf.h@ nsIXMLContentSink.h@
nsIContentSink.h@ nsIIPCSerializableURI.h@ nsIPlatformCharset.h@ nsISpellChecker.h@ nsIXULDocument.h@
nsID.h@ nsIImageToPixbuf.h@ nsIPluginWidget.h@ nsIStatefulFrame.h@ nsImageLoadingContent.h@
nsIDOMClassInfo.h@ nsIInterfaceRequestorUtils.h@ nsIPresShell.h@ nsIStringCharsetDetector.h@ nsInterfaceHashtable.h@
nsIDOMScriptObjectFactory.h@ nsIJSEventListener.h@ nsIPrintDialogService.h@ nsIStyleRule.h@ nsInterfaceRequestorAgg.h@
Assignee | ||
Comment 12•11 years ago
|
||
I believe there was a bug in the build rules impacting Windows. But that shouldn't have impacted any platform with symlinks.
Are you doing any kind of manual clobber, such as deleting bits of dist/include? We don't have explicit rules to install XPIDL-deleted dist/include/.h files if they are deleted (we assume the build system behaves a certain way, which it should as long as you are building through client.mk).
Do you have bug 908977 / ba4acc701c7e in your tree? That should have fixed lingering build dependency issues.
Reporter | ||
Comment 13•11 years ago
|
||
(In reply to Gregory Szorc [:gps] from comment #12)
> I believe there was a bug in the build rules impacting Windows. But that
> shouldn't have impacted any platform with symlinks.
>
> Are you doing any kind of manual clobber, such as deleting bits of
> dist/include? We don't have explicit rules to install XPIDL-deleted
> dist/include/.h files if they are deleted (we assume the build system
> behaves a certain way, which it should as long as you are building through
> client.mk).
The buildslave does this every 24h (you can see the steps on http://buildbot.rhaalovely.net/builders/mozilla-aurora-amd64/builds/873):
- hg qpop -a (in case i have patches to fix build issues in my queue)
- hg pull -u
- hg qpush -a
- gmake -f client.mk configure
- gmake -f client.mk
- gmake -C objdir package
- gmake -f client.mk clean
Of course, all the steps are done only if the previous succeeds. That means the clean step is done only if everything went fine, so that i can have a look at the objdir. In all the previous occurences of that bug, manually rm -Rf'ing the objdir 'fixed' the issue for a day or two, then it usually happens again. SO no, i dont manually purge the objdir, it's an all or nothing thing.
> Do you have bug 908977 / ba4acc701c7e in your tree? That should have fixed
> lingering build dependency issues.
The random failures started happening something like 15 days ago, and now happens on aurora & central, so yes i have that changeset.
Assignee | ||
Comment 14•11 years ago
|
||
|make clean| will blow out dist/. However, it won't delete the .xpt files from config/makefiles/xpidl. As a result, the build system thinks the .h in dist/include are up to date and doesn't reinstall them. We should delete the .xpt files during |make clean|.
Summary: Random build failure with missing nsISupports.h or nsIAtom.h header → make clean doesn't remove xpidl files
Reporter | ||
Comment 15•11 years ago
|
||
(In reply to Gregory Szorc [:gps] from comment #14)
> |make clean| will blow out dist/. However, it won't delete the .xpt files
> from config/makefiles/xpidl. As a result, the build system thinks the .h in
> dist/include are up to date and doesn't reinstall them. We should delete the
> .xpt files during |make clean|.
so you mean i should rather replace my last step by make clobber ?
what recently changed in that area that could trigger that new failure ?
Assignee | ||
Comment 16•11 years ago
|
||
(In reply to Landry Breuil (:gaston) from comment #15)
> (In reply to Gregory Szorc [:gps] from comment #14)
> > |make clean| will blow out dist/. However, it won't delete the .xpt files
> > from config/makefiles/xpidl. As a result, the build system thinks the .h in
> > dist/include are up to date and doesn't reinstall them. We should delete the
> > .xpt files during |make clean|.
>
> so you mean i should rather replace my last step by make clobber ?
> what recently changed in that area that could trigger that new failure ?
I think |make clobber| is busted. Use |mach clobber| or rm -rf the objdir.
We should fix |make clean|. This is fallout from bug 850380.
Depends on: 850380
Reporter | ||
Comment 17•11 years ago
|
||
Another interesting different one:
http://buildbot.rhaalovely.net/builders/mozilla-central-amd64/builds/891
In file included from /var/buildslave-mozilla/mozilla-central-amd64/build/xpcom/base/AvailableMemoryTracker.cpp:22:
../../dist/include/mozilla/Preferences.h:13:10: fatal error: 'nsIPrefService.h' file not found
#include "nsIPrefService.h"
^
1 error generated.
gmake[5]: *** [AvailableMemoryTracker.o] Error 1
gmake[5]: *** Waiting for unfinished jobs....
In file included from /var/buildslave-mozilla/mozilla-central-amd64/build/xpcom/base/CycleCollectedJSRuntime.cpp:60:
In file included from ../../dist/include/mozilla/dom/BindingUtils.h:14:
In file included from ../../dist/include/mozilla/dom/CallbackObject.h:32:
../../dist/include/xpcpublic.h:17:10: fatal error: 'nsIURI.h' file not found
#include "nsIURI.h"
Reporter | ||
Comment 18•11 years ago
|
||
Funky new one too..
http://buildbot.rhaalovely.net/builders/mozilla-central-sparc64/builds/561
In file included from /home/buildslave/mozilla-central-sparc64/build/xpcom/base/AvailableMemoryTracker.cpp:22:0:
../../dist/include/mozilla/Preferences.h:13:28: fatal error: nsIPrefService.h: No such file or directory
compilation terminated.
I'll remove all objdirs and switch to mach clobber on my builders until the issue is fixed.
Reporter | ||
Comment 19•11 years ago
|
||
This bug still affects my c-c builder where i cant really use mach clobber...
Even doing gmake -f client.mk clean + rm -Rf objdir/dist* after a successful build, the next one fails.
http://buildbot.rhaalovely.net/builders/comm-central-amd64/builds/880
Assignee | ||
Comment 20•11 years ago
|
||
I hate having to redefine the targets like this, but it's the simplest
patch. At some point we should merge the two xpidl Makefile.in together.
Attachment #815635 -
Flags: review?(mh+mozilla)
Assignee | ||
Updated•11 years ago
|
Assignee: nobody → gps
Updated•11 years ago
|
Attachment #815635 -
Flags: review?(mh+mozilla) → review+
Assignee | ||
Comment 21•11 years ago
|
||
Status: NEW → ASSIGNED
Flags: in-testsuite-
Comment 22•11 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla27
Updated•7 years ago
|
Product: Core → Firefox Build System
You need to log in
before you can comment on or make changes to this bug.
Description
•