From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.4+) Gecko/20010924 BuildID: 2001092618 Starting Tuesday afternoon every build I've made (incremental, clobber, from completely new source tree) has resulted in the browser crashing when I start mail/news after starting the browser (ie, view mail/news icon on component bar): ld.so.1: ./mozilla-bin: fatal: relocation error: file /home/exodus/tmp/mozilla.bad/components/libgkcontent.so: symbol __1cIDistance6FrknRnsReadingIterator4CH__2_I_: referenced symbol not found Killed As far as I can tell, that's from this code (from inspection of CC -S assembler output): nsCOMPtr<nsIAtom> atom = dont_AddRef(NS_NewAtom(Substring(first, iter))); in nsresult nsXULOutlinerBuilder::TokenizeProperties(const nsAReadableString& aString, nsISupportsArray* aProperties) (around line 1400 of nsXULOutlinerBuilder.cpp). That particular file (nsXULOutlinerBuilder.cpp) hasn't changed recently. I'm using the latest Forte Compilers from Sun. I've been using those compiler for several weeks now with many successful mozilla builds, this is new since Tuesday afternoon. It may very well be a compiler bug. I pulled the nightly build from mozilla.org earlier today and it did not have this problem but was probably built with gcc. Reproducible: Always Steps to Reproduce: 1. Start mozilla normally 2. click on the mail icon in the component bar 3. Actual Results: Application died due to unexpected unresolved symbol. Expected Results: Mail/News window opening.

->outliner

do you have a stack trace for this? Also, are you sure that (somehow) you haven't wound up with some cruft in your components directory? What happens if you delete 'component.reg' and then restart? at any rate, sounds more like platform/build system issues than xptoolkit code.

If I back this out then it looks like everything starts working again (the incremental build isn't finished but what's in the dist directory so far now works): http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Change+Size&hours=2&date=explicit&mindate=09%2F25%2F2001+02%3A34%3A00&maxdate=09%2F25%2F2001+02%3A35%3A59&cvsroot=%2Fcvsroot It restores the missing symbol to libstring_s.a and libxpcom.so: ./lib/libstring_s.a [52] | 200| 76|FUNC |GLOB |0 |2 |__1cIDistance6FrknRnsReadingIterator4CH__2_I_ ./lib/libxpcom.so [4357] | 877932| 76|FUNC |GLOB |0 |10 |__1cIDistance6FrknRnsReadingIterator4CH__2_I_

Have you tried clobbering your build?

Noted above: > I'm using the latest Forte Compilers from Sun. Possibly they don't like some of that template-fu. Pav, you've the Forte stuff?

As mentioned in the very first comment I found this on an incremental build, then tried a clobber build, then pulled a completely new source tree. This is 100% reproducible no matter how I build. As far as I can tell exactly one reference to that function is being generated, no other object files in the tree refer to it. Until I back out that one fix and then references to that symbol show up everywhere.

Sorry, I missed your note that you tried a clobber build. /me investigates

I pulled a completely new tree and built with the Sun Workshop 6 Update 1 compilers and reproduced this problem. For the past few weeks I've been (successfully until Tuesday) using a snapshot of the next upcoming Forte release so I wanted to verify that older released compilers encountered the same problem. They do.

Try upgrading to WS6U2. We're running it on nebiros for weeks and it doesn't show this problem. Reassigning to jag since it was his checkin that triggered this.

The compiler I've been using for weeks is a current stable snapshot of WS7 (Forte 7). I only tried WS6U1 as a second opinion to see if the results were identical (and they were). I'll see if I can try WS6U2, I'm downloading it now. Can someone check the object files on your build machine for the relevant symbols? mozilla does start fine and may even pass generic browser tests, it just dies when you try mailnews.

The build with WS6U2 is finished, it has the same exact problem: ./lib/libgkconxultmpl_s.a [344] | 0| 0|FUNC |GLOB |0 |UNDEF |__1cIDistance6FrknRnsReadingIterator4CH__2_I_ ./lib/components/libgkcontent.so [25180] | 0| 0|FUNC |GLOB |0 |UNDEF |__1cIDistance6FrknRnsReadingIterator4CH__2_I_ And that symbol isn't defined in any other object. % CC -V CC: Sun WorkShop 6 update 2 C++ 5.3 2001/05/15 % Here is my .mozconfig file: # sh # Build configuration script # # See http://www.mozilla.org/build/unix.html for build instructions. # # Options for client.mk. mk_add_options MOZ_MAKE_FLAGS=-j3 # Options for 'configure' (same as command-line options). ac_add_options --enable-optimize="-O -xO4 -xtarget=ultra3 -xspace -xildoff" ac_add_options --enable-ultrasparc ac_add_options --enable-crypto ac_add_options --disable-tests ac_add_options --disable-debug ac_add_options --without-jpeg ac_add_options --without-zlib ac_add_options --without-png

So when I build on linux using gcc (egcs-2.91.66), without -O, I get Substring__FRCt17nsReadingIterator1ZUsT0, and no Distance symbol in libgkconxultmpl_s.a. When I build with -O or -O3, I get Distance__FRCt17nsReadingIterator1ZUsT0, and no Substring symbol. My libstring_s.a contains Distance__FRCt17nsReadingIterator1ZUsT0 for both -O3 and no -O, and doesn't contain Substring__FRCt17nsReadingIterator1ZUsT0 in either case.

*** Bug 103028 has been marked as a duplicate of this bug. ***

Btw, I did verify the crash using Greg's config & WS6U2 (both with & without the crazy optimization options).

Does someone have the cycles to investigate what's going on here? Again, it looks like it's a problem with the compiler.

An attempt to build a StaticBuild Mozilla using the Workshop compiler fails with the following error... I assume it's the same problem as this one: -- snip -- /opt/SUNWspro/bin/CC -o mozilla-bin -I/usr/openwin/include -mt -O -DDEBUG -DDEBUG_mozilla -DTRACING -g -DWIDGET_DLL=\"libwidget_gtk.so\" -DGFXWIN_DLL=\"libgfx_gtk.so\" -I/usr/local/lib/glib/include -I/usr/local/include -I/usr/openwin/include nsAppRunner.o nsSetupRegistry.o nsWindowCreator.o nsSigHandlers.o showOSAlert.o nsStaticComponents.o -xildoff -L../../dist/bin -L../../dist/lib -L../../dist/lib/components -lxpconnect -ljsloader -lxpctest -ltimer_gtk -lnkcache -lnecko -lnecko2 -luriloader -luconv -lucvja -lucvcn -lucvlatin -lucvtw -lucvtw2 -lucvko -lucvibm -lucvmath -lunicharutil -lnslocale -lstrres -llwbrk -lchardet -lpref -loji -lcaps -lchrome -lrdf -lhtmlpars -lgfxps -lgfx_gtk -lgfxxprint -lgfx2 -limglib2 -limgppm -limgpng -limggif -limgjpeg -lgkplugin -lnpsimple -ljsurl -ljsdom -lgkview -lwidget_gtk -lxremote_client -lgkcontent -lgklayout -lmork -ldocshell -lembedcomponents -lwebbrwsr -lcomposer -ltxmgr -ltxtsvc -lprofile -lnsprefm -laccessibility -lnsappshell -lmozfind -lregviewer -lmozxfer -lshistory -lappcomps -lxremoteservice -lmozbrwsr -lpipnss -lpippki -lmozldap -lcookie -lwallet -lwalletviewers -lxmlextras -ltransformiix -lmailnews -lmsgdb -lmsgnews -llocalmail -lmimeemitter -lvcard -lsmimestb -lmime -lmsgcompose -lmsgimap -laddrbook -limport -limpText -labsyncsvc -lmozjs -lxptinfo -lxpcom -ljsj -lmozz -lmozjpeg -lgtksuperwin -lgtkxtbin -lmozpng -lmozmng -lxlibrgb -lgkgfx -lgtkembedmoz -lmsgbaseutil -L../../dist/lib -lmozpng -L../../dist/lib -lmozmng -L../../dist/lib -lmozjpeg -L../../dist/lib -lmozz -lXIE -L/usr/openwin/lib -R/usr/openwin/lib -lXp -lXext -lX11 ../../dist/lib/libcrmf.a ../../dist/lib/libssl.a ../../dist/lib/libnss.a ../../dist/lib/libssl.a ../../dist/lib/libpkcs12.a ../../dist/lib/libpkcs7.a ../../dist/lib/libcerthi.a ../../dist/lib/libpk11wrap.a ../../dist/lib/libcryptohi.a ../../dist/lib/libcerthi.a ../../dist/lib/libpk11wrap.a ../../dist/lib/libsoftoken.a ../../dist/lib/libcertdb.a ../../dist/lib/libfreebl.a ../../dist/lib/libsecutil.a ../../dist/lib/libdbm.a -lldap40 -llber40 -L/usr/openwin/lib -R/usr/openwin/lib -lXt -L../../dist/bin -lxpcom -ljsj -L/shared/bigtmp/mozilla/2001-10-06-08-trunk/objdir_ws6_gtk_static/dist/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl -L/usr/local/lib -L/usr/openwin/lib -R/usr/openwin/lib -lgtk -lgdk -lgmodule -lglib -ldl -lXext -lX11 -lsocket -lnsl -lm -lsocket -ldl -lm Undefined first referenced symbol in file unsigned Distance(const nsReadingIterator<unsigned short>&,const nsReadingIterator<unsigned short>&) ../../dist/lib/components/libgkcontent.a(nsXULOutlinerBuilder.o) ld: fatal: Symbol referencing errors. No output written to mozilla-bin gmake[1]: *** [mozilla-bin] Error 1 gmake[1]: Leaving directory `/shared/bigtmp/mozilla/2001-10-06-08-trunk/objdir_ws6_gtk_static/xpfe/bootstrap' gmake: *** [install] Error 2 -- snip --

Can anyone check whether this issue exists in the 0.9.5_branch, too ? This looks like a milestone blocker for me...

Comment on attachment 52530 [details] [diff] [review] patch for 2001-10-06-08-trunk (more a workaround than a real fix) r=jag

BTW: The real cause of this bug is more or less described in http://lxr.mozilla.org/seamonkey/source/string/public/nsStringIteratorUtils.h#41 My patch is only a workaround - this issue can pop-up again anytime, anywhere and is hard to track... Can anyone please file a bug to fix that, please ?

StaticBuild compiles now without problems (but crashes at startup, I filed bug 103746 for that issue) ...

Greg: could you see if this patch does the trick for you?

Yes, I un-backed-out the changes that introduced this and applied the workaround. All seems well, no trace of the unresolved symbol. Thanks, Roland.

*** Bug 103008 has been marked as a duplicate of this bug. ***

Roland, this is just a wild guess. Could you see if this instead of the first patch fixes your problem?

Nope, the new patch does not fix it... ;-( It still goes to hell when I try to open the DOM inspector: -- snip -- ###!!! ASSERTION: Popup set is already defined! Only 1 allowed.: '!mPopupSetFrame', file ../../../../../../../src/2001-10-15-08-trunk/mozilla/layout/xul/base/src/nsRootBoxFrame.cpp, line 302 ###!!! Break: at file ../../../../../../../src/2001-10-15-08-trunk/mozilla/layout/xul/base/src/nsRootBoxFrame.cpp, line 302 ld.so.1: ./mozilla-bin: fatal: relocation error: file /home/mozilla/builds/2001-10-15-08-trunk/objdir_ws6_xlib/dist/bin/components/libgkcontent.so: symbol __1cIDistance6FrknRnsReadingIterator4CH__2_I_: referenced symbol not found Killed -- snip --

Roland: could you e-mail me the pre-processed output of content/xul/templates/src/nsXULOutlinerBuilder.cpp without and with your patch?

It would be nice to check-in my workaround for now. I have reports that this issue always "happens" with the current recommended patch cluster for Solaris 7 and the newest Sun Workshop 6U2 patch set (AFAIK "nebiros" wasn't updated yet...).

Work-around checked in. -> future, helpwanted for figuring out what the right fix for this is.

We hit this issue another time, see bug 135731 ("opening address book crashes mozilla") ...

*** Bug 167722 has been marked as a duplicate of this bug. ***

I also am seeing this except now its in libnecko I am using Forte 7 with the latest patches for C and C++ from sunsolve also using Solaris 9 with what as of 9/18/02 is the latest patch cluster Here is my environment # env CC=/opt/SUNWspro/bin/cc CXX=/opt/SUNWspro/bin/CC PATH=/usr/sbin:/usr/bin:/usr/dt/bin:/usr/openwin/bin:/bin:/usr/ccs/bin:/opt/SUNW spro/bin:/usr/local/bin:/usr/ucb LD_LIBRARY_PATH=/usr/lib:/usr/sfw/lib:/usr/local/lib # cat .mozconfig mk_add_options MOZ_MAKE_FLAGS=-j4 ac_add_options --disable-tests ac_add_options --disable-debug ac_add_options --enable-optimize=-xO2 ac_add_options --without-system-nspr ac_add_options --without-system-zlib ac_add_options --without-system-jpeg ac_add_options --without-system-png ac_add_options --without-system-mng ac_add_options --enable-crypto

Donnie Cranford wrote: > I also am seeing this except now its in libnecko > > I am using Forte 7 with the latest patches for C and C++ from sunsolve > also using Solaris 9 with what as of 9/18/02 is the latest patch cluster I don't see this in Solaris 2.7/SPARC with Sun Workshop 7+latest WS patches... what's your buildid ?

Roland, I have given more info on this in bug 167722

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

Our code and compilers have evolved, I don't think there's any valid information for current issues left here.