I just updated and my non-debug, optimized build crashes at startup after "WEBSHELL += 2". The last working build was from 2000-03-07, IIRC. Sorry for this bad report, but I dunno, how to debug this, as I can't do a backtrace (i think, at least).
Happens for ./mozilla ./mozilla -mail ./mozilla -pref ./mozilla -edit ./mozilla -addressbook Does /not/ happen for ./mozilla -ProfileManager I can create a new profile, but when I start up with it (or my migrated one), same crash.
maybe strace could show you what it was up to just before it died? That's going to be a huge log though... grepping it for opens may give you some better idea of what files mozilla is working with just before it dies (and thus what it was up to). My build from last night is fine, have you tried just doing a clobber build?
Maybe it's my j4. I disabled it and am doing a fresh build ("make realclean; make") now. Previous builds went fine with it :-/.
No, it wasn't -j4. Some headers (autogenerated from .idl files) from mozilla/extensions/ were not built; I had to do a manual make in some subdirs (psm-glue, cookie and maybe pics). Changing to COMPONENT Build Config. Tnx puetzk for the hint to rebuild.
Severity: blocker → normal
Component: Browser-General → Build Config
QA Contact: asadotzler → cyeh
Forgot the owner
Assignee: cbegle → cls
Details, details. Compiler, libc, gtk version? Precise options given to configure? Exact idls that were not properly generated?
Compiler: gcc 2.95.2 glibc: 2.1.2 (RH6.0 + RH6.1 packages) gtk/glib: both 1.2.3-1 .mozconfig: # Options for client.mk. mk_add_options MOZ_CVS_FLAGS="-q -z 9" mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objmoz-@CONFIG_GUESS@ #mk_add_options MOZ_MAKE_FLAGS=-j4 # Options for 'configure' (same as command-line options). ac_add_options --disable-tests ac_add_options --enable-optimize ac_add_options --disable-debug ac_add_options --enable-strip-libs Exact idls: Phew. *IIRC*, It was cookie/nsICookieService.h and psm-glue/nsIPSMComponent.idl. It looked to me, as if it stops at the first header (from extensions/) needed. I just noticed, that cookie doesn't include any idl's at all (I was falsely assuming the idl because of the "nsI" prefix), so it's at least the first make pass in extensions' subdirs, which was missing.
I should note, that I don't have any "objmoz-*" at all in /usr/src or its subdirs (mozilla resides in /usr/src/mozilla). /usr/src is a symlink, if that matters.
Is this problem still occurring? I was not able to reproduce it with my optimized build.
Yes. It looks that way. When I updated some days ago (with tha last update being > week ago), I had the same problem. When I just updated, I got no such compile errors, but a |make| in extensions/[cookies|wallet|psm-glue] caused additional compilations. Maybe just no interfaces changed between the 2 updates/compiles. To make sure, I'm not doing something stupid (or forgetting something): I did make -f client.mk checkout ./configure make This gives me the build-ID "2000030708" (the time of my last clobber). Also, I'm building the tip (|:pserver:email@example.com:/cvsroot|). Changing SUMMARY from "Crash at startup after "WEBSHELL += 2"" to "|extensions/|'s subdirs not built". If I do a |make| in extensions, only xmlterm is made. No surprise, my |extensions/Makefile| reads [...] #DIRS = $(MOZ_EXTENSIONS) DIRS = xmlterm [...]
Summary: Crash at startup after "WEBSHELL += 2" → |extensions/|'s subdirs not built
Doesn't seem to be that simple. I edited extensions/Makefile to include DIRS = wallet cookie pics xmlterm (which also propagated to Makefile), but it didn't help. After |make realclean;./configure;make|, I'm still getting nsJAR.cpp:37: nsIPSMComponent.h: No such file or directory A make in extensions compiled the subdirs, but stoped with nsPICS.cpp: In method `nsresult nsPICS::GetWebShell(unsigned int, nsIWebShellServices *&)': nsPICS.cpp:574: no matching function for call to `nsIDocumentLoader::GetContentViewerContainer (PRUint32 &, nsIContentViewerContainer **)' ../../../dist/include/nsIDocumentLoader.h:53: candidates are: nsresult nsIDocumentLoader::GetContentViewerContainer(nsISupports *, nsIContentViewerContainer **) [...] make: *** [nsPICS.o] Error 1 So, I made sure, that at least wallet, cookie and psm-glue are compiled and restarted the build (which is running now).
> I edited extensions/Makefile to include s/Makefile/Makefile.in
The problem in pics seems to be unrelated; filed bug #34205. Apart from that, compile went fine.
Ok, there's way too much baggage here. Start from a fresh tree and see if the problem with extensions still exists. You can't just set extensions to xmlterm as some code still requires the interface headers for wallet & cookie (Bug #18352). You need to use --with-extension=default,xmlterm if you want to build xmlterm. Also, last I checked, pics is no longer used/supported. The problem with nsIPSMComponent.h stems from not building in extensions/psm-glue.
I did't use --with-extensions, when this bug appeared (see my .mozconfig above). I'll do a fresh pull with the next good opportunity.
That's my point. You modified the extensions/Makefile when you should've used --with-extensions. Back to the original problem. Once you've completed your fresh build, are you still having problems with the WEBSHELL leaks?
The WEBSHELL problem appeared only in one build (the first one). You might be right, that I modified extensions/Makefile (for whatever reason - I did know --with-extensions) a very long time ago :-(. Ignore this bug for now; I'll do a fresh pull in the next weeks and check, if the problem still exists. For the case, it was my fault: I'm sorry.
Closing comments: Could not duplicate the original problem with WEBSHELL crash. Reporter does not appear to still be experiencing that problem. The problem with building in extensions is operator error. :)
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → WORKSFORME
I pulled a fresh tree (|rm -rf mozilla; tar xzf mozilla-source.tar.gz; cd mozilla; export CVSROOT [...]; make -f client.mk checkout|) and the same problem occurs. Build stops with nsJAR.cpp:37: nsIPSMComponent.h: No such file or directory REOPENing. A |make| in extensions/ after that seems to work correctly, however.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Wait, I'm not sure, if |make| in extensions/ really works correctly under normal circumstances, because my current |.mozconfig| is: [...] mk_add_options MOZ_CVS_FLAGS="-q -z 9" mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objmoz-@CONFIG_GUESS@ mk_add_options MOZ_MAKE_FLAGS=-j4 # Options for 'configure' (same as command-line options). ac_add_options --disable-tests ac_add_options --enable-optimize ac_add_options --disable-debug ac_add_options --enable-strip-libs #ac_add_options --enable-jprof #workaround for bug ac_add_options --with-extensions=wallet,cookie,psm-glue
Ok, I pasted your .mozconfig into mine, commented out the extensions option and it built fine. How old is that source tarball you are using? It sounds as though something's not being updated correctly. What does your config/autoconf.mk list for the MOZ_EXTENSIONS variable?
The tarball is from 2000-04-10 (nightly/latest). MOZ_EXTENSIONS was and is identical to --with-extensions, but with spaces instead of commas. It was "wallet cookie pics xmlterm" in the first run (didn't work, because PICS doesn't currently buid) and is now "wallet cookie psm-glue". I just remembered, that I use make 3.77, if that matters. I never experienced any problems with infinitive loops however.
Can you still duplicate this error? I ran into a stupid typo in allmakefiles.sh a couple of days ago that was preventing the psm-glue Makefiles from being generated at configure time. We have the ability to generate Makefiles on the fly but apparently it's not working perfectly.
mass re-assign of all bugs where i was listed as the qa contact
QA Contact: cyeh → chofmann
Fixing the typo in allmakefiles.sh should have fixed this problem.
Status: REOPENED → RESOLVED
Last Resolved: 19 years ago → 19 years ago
Resolution: --- → FIXED
My current .mozconfig: [...] ac_add_options --with-extensions=wallet,cookie,psm-glue I didn't have any problem after my fresh checkout/build at 10th or so this month. VERIFIED.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.