242382 - Trunk build failure in nsObjectFrame.cpp

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect, P1)

Description

[Roland Mainz]

2004-05-02-trunk on Solaris 2.8/SPARC, compiling the sources with Sun Workshop 8
ends in the following error:
-- snip --
nsObjectFrame.cpp
Building deps for ../../../../../mozilla/layout/html/base/src/nsObjectFrame.cpp
/opt/SUNWspro/bin/CC -o nsObjectFrame.o -c -DOSTYPE=\"SunOS5\"
-DOSARCH=\"SunOS\" -D_IMPL_NS_LAYOUT -I../../../../../mozilla/layout/
html/base/src/../../../xul/base/src
-I../../../../../mozilla/layout/html/base/src/../../../xul/content/src
-I../../../../../mozilla/
layout/html/base/src/../../style/src
-I../../../../../mozilla/layout/html/base/src/../../forms/src
-I../../../../../mozilla/layout/h
tml/base/src/../../../base/src -I../../../../../mozilla/layout/html/base/src 
-I../../../../dist/include/xpcom -I../../../../dist/in
clude/string -I../../../../dist/include/dom -I../../../../dist/include/content
-I../../../../dist/include/gfx -I../../../../dist/inc
lude/widget -I../../../../dist/include/locale -I../../../../dist/include/view
-I../../../../dist/include/necko -I../../../../dist/in
clude/js -I../../../../dist/include/caps -I../../../../dist/include/pref
-I../../../../dist/include/htmlparser -I../../../../dist/in
clude/webshell -I../../../../dist/include/plugin
-I../../../../dist/include/docshell -I../../../../dist/include/mimetype
-I../../../
../dist/include/webbrwsr -I../../../../dist/include/oji
-I../../../../dist/include/util -I../../../../dist/include/unicharutil -I../
../../../dist/include/lwbrk -I../../../../dist/include/imglib2
-I../../../../dist/include/accessibility -I../../../../dist/include/x
pconnect -I../../../../dist/include/java -I../../../../dist/include/exthandler
-I../../../../dist/include/intl -I../../../../dist/in
clude/uconv -I../../../../dist/include/ctl -I../../../../dist/include/layout
-I../../../../dist/include -I/shared/bigtmp/mozilla/nig
htlybuilds/north/weekend/mozilla_gtk1/objdir_gtk1/dist/include/nspr    
-I/usr/openwin/include   -KPIC  -I/usr/openwin/include -feat
ures=tmplife -xbuiltin=%all -mt  -DNDEBUG -DTRIMMED -xO2  -I/usr/openwin/include
-DMOZILLA_VERSION=\"1.8a\" -DSOLARIS=1 -DNSCAP_DISA
BLE_DEBUG_PTR_TYPES=1 -DD_INO=d_ino -DSTDC_HEADERS=1 -DHAVE_ST_BLKSIZE=1
-DHAVE_SIGINFO_T=1 -DHAVE_INT16_T=1 -DHAVE_INT32_T=1 -DHAVE
_INT64_T=1 -DHAVE_UINT=1 -DHAVE_UINT_T=1 -DHAVE_UINT16_T=1 -DHAVE_DIRENT_H=1
-DHAVE_SYS_BYTEORDER_H=1 -DHAVE_MEMORY_H=1 -DHAVE_UNIST
D_H=1 -DHAVE_NL_TYPES_H=1 -DHAVE_MALLOC_H=1 -DHAVE_X11_XKBLIB_H=1
-DHAVE_SYS_STATVFS_H=1 -DHAVE_SYS_STATFS_H=1 -DHAVE_LIBM=1 -DHAVE_
LIBDL=1 -DHAVE_LIBSOCKET=1 -DFUNCPROTO=15 -DHAVE_XSHM=1 -D_REENTRANT=1
-DHAVE_RANDOM=1 -DHAVE_STRERROR=1 -DHAVE_LCHOWN=1 -DHAVE_FCHM
OD=1 -DHAVE_SNPRINTF=1 -DHAVE_MEMMOVE=1 -DHAVE_RINT=1 -DHAVE_STAT64=1
-DHAVE_LSTAT64=1 -DHAVE_NL_LANGINFO=1 -DHAVE_FLOCKFILE=1 -DHAV
E_LOCALTIME_R=1 -DHAVE_STRTOK_R=1 -DVA_COPY=va_copy -DHAVE_VA_COPY=1
-DHAVE_I18N_LC_MESSAGES=1 -DMOZ_DEFAULT_TOOLKIT=\"gtk\" -DMOZ_W
IDGET_GTK=1 -DMOZ_ENABLE_XREMOTE=1 -DMOZ_X11=1 -DMOZ_APP_NAME=\"mozilla\"
-DMOZ_ENABLE_COREXFONTS=1 -DMOZ_EXTRA_X11CONVERTERS=1 -DOJ
I=1 -DIBMBIDI=1 -DMOZ_VIEW_SOURCE=1 -DACCESSIBILITY=1 -DMOZ_XPINSTALL=1
-DMOZ_JSLOADER=1 -DHAVE_GSSAPI_GSSAPI_H=1 -DHAVE_GSS_C_NT_HO
STBASED_SERVICE=1 -DMOZ_MATHML=1 -DMOZ_SVG=1 -DMOZ_SVG_RENDERER_LIBART=1
-DMOZ_LOGGING=1 -DMOZ_USER_DIR=\".mozilla\" -DHAVE_ALLOCA_H
=1 -DHAVE_ALLOCA=1 -DMOZ_XUL=1 -DMOZ_PROFILESHARING=1 -DMOZ_PROFILELOCKING=1
-DSUNCTL=1 -DMOZ_DLL_SUFFIX=\".so\" -DXP_UNIX=1 -DUNIX_
ASYNC_DNS=1 -DJS_THREADSAFE=1 -DNS_PRINT_PREVIEW=1 -DNS_PRINTING=1
-DMOZILLA_LOCALE_VERSION=\"1.8a\" -DMOZILLA_REGION_VERSION=\"1.8a
\" -DMOZILLA_SKIN_VERSION=\"1.5\"  -D_MOZILLA_CONFIG_H_ -DMOZILLA_CLIENT
../../../../../mozilla/layout/html/base/src/nsObjectFrame.c
pp
 >> Assertion:  unexpected array kind in type_builder::visit_array
(../lnk/v2mangler.cc, line 1287)
    while processing
../../../../../mozilla/layout/html/base/src/nsObjectFrame.cpp at line 884.
gmake[5]: *** [nsObjectFrame.o] Error 1
gmake[5]: Leaving directory
`/shared/bigtmp/mozilla/nightlybuilds/north/weekend/mozilla_gtk1/objdir_gtk1/layout/html/base/src'
gmake[4]: *** [libs] Error 2
gmake[4]: Leaving directory
`/shared/bigtmp/mozilla/nightlybuilds/north/weekend/mozilla_gtk1/objdir_gtk1/layout/html/base'
gmake[3]: *** [libs] Error 2
gmake[3]: Leaving directory
`/shared/bigtmp/mozilla/nightlybuilds/north/weekend/mozilla_gtk1/objdir_gtk1/layout/html'
gmake[2]: *** [libs] Error 2
gmake[2]: Leaving directory
`/shared/bigtmp/mozilla/nightlybuilds/north/weekend/mozilla_gtk1/objdir_gtk1/layout'
gmake[1]: *** [tier_9] Error 2
gmake[1]: Leaving directory
`/shared/bigtmp/mozilla/nightlybuilds/north/weekend/mozilla_gtk1/objdir_gtk1'
gmake: *** [default] Error 2
-- snip --

Comment 1

[Boris Zbarsky [:bzbarsky]]

Line 884 of nsObjectFrame.cpp is:

884     aPresContext->GetScaledPixelsToTwips(&p2t);

I fail to see how this could possibly fail to compile...

Moreover, none of the code near that line has changed in months.

So something fishy is going on.  What's the last build that compiled?

Comment 2

[Roland Mainz]

Boris Zbarsky wrote:
> Line 884 of nsObjectFrame.cpp is:
> 884     aPresContext->GetScaledPixelsToTwips(&p2t);
> I fail to see how this could possibly fail to compile...

Yeah, /me, too...

> Moreover, none of the code near that line has changed in months.
> So something fishy is going on.  What's the last build that compiled?

Last successfull build has the timestamp "2004-04-25-04-trunk" ...

Comment 3

[Boris Zbarsky [:bzbarsky]]

So builds from the 26th fail?  Or were not tried?

I can see some compilers getting confused by the patches that landed for bug 
226439... Can you try revision 1.447 of nsObjectFrame and seeing if that builds?
 If so, what about revisions 1.448 and 1.449?  You can safely just update the
one file; all those revisions should build against the current tip of everything
else.

Comment 4

[Greg Onufer]

I switched to a newer compiler and the compiler-internal assertion went away.

CC: Sun C++ 5.6 DEV 2004/04/27

It would be interesting to compare the pre-processed source files from
before/after the breakage.  _Something_ cha nged to break the compiler (even if
it's the compiler that is at fault here).

Comment 5

[Roland Mainz]

Boris Zbarsky wrote:
> So builds from the 26th fail?  Or were not tried?

Not tried. The Build machine is still an Ultra5/333MHz and that box still has
many many duties, the current cycle time for all builds
(mozilla/firefox/thunderbird) with both toolkits (gtk1, gtk2) is around two
days. Other issues may even cause longer delays. But as soon as I've setup my
Blade2500 we should get daily nighlies regardless what happens. :)

Comment 6

[Roland Mainz]

Greg Onufer wrote:
> I switched to a newer compiler and the compiler-internal assertion went away.
> CC: Sun C++ 5.6 DEV 2004/04/27

Unfortunately the lastest compiler patches available to the _public_ don't solve
the issue.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Roland, the testing I asked for in comment 3 just needs building in
layout/html/base/src and layout/build.  It shouldn't take more than an hour or
two to do it one or two times, no matter what.  Mind doing it?

Comment 8

[Boris Zbarsky [:bzbarsky]]

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

Comment 9

[Roland Mainz]

Boris Zbarsky wrote:
> Roland, the testing I asked for in comment 3 just needs building in
> layout/html/base/src and layout/build.  It shouldn't take more than an hour or
> two to do it one or two times, no matter what.  Mind doing it?

Not this weekend... I am punished with a hardware problem right now and I am now
restricted to do Mozilla hacking on Linux... sorry... ;-(

Comment 10

[Iain MacDonnell]

As far as I can tell, this problem carries back at least as far as r1.446 of
nsObjectFrame.cpp. If I try to go back further than that, I run into other
inconsistencies.

This is assuming I'm getting the CVS semantics right - I'm not fluent.

/export/stuff/mozilla/thunderbird-20040507/mozilla/layout/html/base/src% cvs up
-r 1.446 nsObjectFrame.cpp
RCS file: /cvsroot/mozilla/layout/html/base/src/nsObjectFrame.cpp,v
retrieving revision 1.445
retrieving revision 1.446
Merging differences between 1.445 and 1.446 into nsObjectFrame.cpp
M nsObjectFrame.cpp
/export/stuff/mozilla/thunderbird-20040507/mozilla/layout/html/base/src% gmake libs
nsObjectFrame.cpp
Building deps for nsObjectFrame.cpp
...CC line...
 >> Assertion:  unexpected array kind in type_builder::visit_array
(../lnk/v2mangler.cc, line 1288)
    while processing nsObjectFrame.cpp at line 885.
gmake: *** [nsObjectFrame.o] Error 1

Comment 11

[Boris Zbarsky [:bzbarsky]]

That does look like the right CVS command, but rev 1.446 is dated "2004-04-15
13:56", which is significantly before this bug was claimed to first appear....

Also, it looks like your file is locally modified, so what you're testing is not
a vanilla revision 1.446.  If you don't have edits you're aware of in it, you
may want to remove it and then update to 1.446 and see what happens.

Comment 12

[Iain MacDonnell]

Uhh, ok... I hadn't made any manual edits, but had been flipping between
revisions. So, now...

/export/stuff/mozilla/thunderbird-20040507/mozilla/layout/html/base/src% rm
nsObjectFrame.cpp
/export/stuff/mozilla/thunderbird-20040507/mozilla/layout/html/base/src% cvs up
-r 1.447 nsObjectFrame.cpp
U nsObjectFrame.cpp
/export/stuff/mozilla/thunderbird-20040507/mozilla/layout/html/base/src% gmake libs
nsObjectFrame.cpp
Building deps for nsObjectFrame.cpp
...CC line...
"nsObjectFrame.cpp", line 3803: Error: Too many arguments in call to
"nsPIDOMWindow::GetRootFocusController()".
1 Error(s) detected.
gmake: *** [nsObjectFrame.o] Error 1


If I then rm again, and go to v1.448, the "unexpected array kind" assertion
reappears.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Yeah, well.  When I said that revision 1.447 would build against current trunk,
it was true; it wasn't until about 12 hours later that the PIDOMWindow changes
happened.

In any case, it definitely sounds like this is barfing on the templates bug
226439 introduced.  Can you try the following, please:

rm nsObjectFrame.cpp
cvs up -A nsObjectFrame.cpp
cvs up -j 1.448 -j 1.447 nsObjectFrame.cpp

(this last just backs out the bug 226439 changes).

Then try building it.

Comment 14

[Iain MacDonnell]

That doesn't appear to have helped... cvs acted like this:

/export/stuff/mozilla/thunderbird-20040507/mozilla/layout/html/base/src% rm
nsObjectFrame.cpp
/export/stuff/mozilla/thunderbird-20040507/mozilla/layout/html/base/src% cvs up
-A nsObjectFrame.cpp
U nsObjectFrame.cpp
/export/stuff/mozilla/thunderbird-20040507/mozilla/layout/html/base/src% cvs up
-j 1.448 -j 1.447 nsObjectFrame.cpp
RCS file: /cvsroot/mozilla/layout/html/base/src/nsObjectFrame.cpp,v
retrieving revision 1.448
retrieving revision 1.447
Merging differences between 1.448 and 1.447 into nsObjectFrame.cpp
/export/stuff/mozilla/thunderbird-20040507/mozilla/layout/html/base/src% 

but I still get

 >> Assertion:  unexpected array kind in type_builder::visit_array
(../lnk/v2mangler.cc, line 1288)
    while processing nsObjectFrame.cpp at line 882.
gmake: *** [nsObjectFrame.o] Error 1

Comment 15

[Boris Zbarsky [:bzbarsky]]

OK.  Can you keep backing out revisions one by one, like that, except for
revision 1.453 (which is the PIDOMWindow change) and see whether you can locate
the problem?

Alternately, you could try pulls by date from the days Roland didn't have builds
from....

Comment 16

[Iain MacDonnell]

OK, it got better after I got to "cvs up -j 1.451 -j 1.450 nsObjectFrame.cpp"...

... but it looks like there's another instance:

 >> Assertion:  unexpected array kind in type_builder::visit_array
(../lnk/v2mangler.cc, line 1288)
    while processing nsPresShell.cpp at line 4249.
gmake: *** [nsPresShell.o] Error 1

Comment 17

[Boris Zbarsky [:bzbarsky]]

Looks like this compiler can't handle the templated nsAString form of EqualsLiteral.

What ifdef does one use to identify this compiler so we can tell it to use the
non-template form?

Comment 18

[Iain MacDonnell]

__SUNPRO_CC should be defined. If it's a compiler _bug_, though, maybe this
isn't the right thing to do. What's the down-side of not using the template
form?
 

Comment 19

[Boris Zbarsky [:bzbarsky]]

> What's the down-side of not using the template form?

It's a little slower (strlen vs templating on the length of a literal string).

And yes, this is a compiler bug.  roc was expecting some of those, which is why
the non-template code is there... See bug 226439 for details.

Also, what versions of __SUNPRO_CC would we want to screen out, given comment 4?

Comment 20

[Iain MacDonnell]

> Also, what versions of __SUNPRO_CC would we want to screen out, given comment 4?

That's kindof my point. I don't think __SUNPRO_CC is granular enough for this -
it's 0x560 for the EA2 version of Sun Studio 9 (the version that fails). I think
it'll probably be the same for the released version (coming July-ish), which
should work, given comment 4.

I wonder if this bug is also in older (ie. 5.5) versions of the compiler. I'll
see if I can find time to check tomorrow. If it's not, maybe we need to
recommend using the 5.5 version until 5.6 is officially released. Not ideal :/

BTW, I manually fixed nsPresShell.cpp to use the non-template form, and
that builds ok now too, so it looks like we're barking up the right tree
at least :)

Comment 21

[Roland Mainz]

Boris Zbarsky wrote:
> Also, what versions of __SUNPRO_CC would we want to screen out, given comment 
> 4?

That is a question for gonufer... he has a more recent internal version of the
compiler - he only has to dump the value here... :)
And we have to get someone from the compiler folks (Mary?!) to look at the issue
and check whether it is possible to backport the fix from trunk.

Comment 22

[Greg Onufer]

(In reply to comment #21)
> That is a question for gonufer... he has a more recent internal version of the
> compiler - he only has to dump the value here... :)

The compilers I'm using say 0x560.

Comment 23

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'll leave it up to you Sun compiler users to figure out what to do here.

Comment 24

[Iain MacDonnell]

I can't think of a *good* answer... maybe put a temporary fix (ie. use the less
effecient form) until Sun Studio 9 ships in July, then remove it - keep this bug
open until then ... ?

Comment 25

[Boris Zbarsky [:bzbarsky]]

The answer should be to ifdef the template such that it's only on for
sufficiently new versions of the compiler, whatever that means in this case. 
See 
http://lxr.mozilla.org/seamonkey/source/xpcom/string/public/nsSubstring.h#48 and
http://lxr.mozilla.org/seamonkey/source/xpcom/string/public/nsAString.h#54

That will let the old compilers build and the new one use the template, since it
can.

This is the part where knowing what defines to check for comes in.

Comment 26

[Iain MacDonnell]

Except the latest publically available version of the compiler (Sun Studio 9
Early Access 2) has the bug (see comment 6). We know that the final release of
SS9 will have the fix, but it's not available until July, so anyone who upgraded
to the EA2 version would have to revert...

Comment 27

[Roland Mainz]

Umpf... sometimes I wish the people would feel more responsible for stuff they
broke...

... talking thix xx@@@!!!-bug myself...

Comment 28

[Roland Mainz]

Attachment: Patch for 2004-05-09-trunk

Comment 29

[Roland Mainz]

Comment on attachment 148613 [details] [diff] [review]
Patch for 2004-05-09-trunk

Requesting r=/sr= ...

Comment 30

[Roland Mainz]

gonufer:
Do you think it's worth to escalate this issue internally and request a backport
for the fix to Forte 8 ?

Comment 31

[Roland Mainz]

Setting QA to [e-mail]... :)

Comment 32

[Roland Mainz]

roc:
Thanks for the r+/sr+ ... can you check the patch "in", please ?

Comment 33

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Taking for checkin.

Comment 34

[Iain MacDonnell]

If it gets checked in before 22:40 PDT today, my automated nightly build will
test it - I've set it to use this compiler:

% CC -V
CC: Sun C++ 5.5 Patch 113817-08 2004/04/13
% 

I believe this is the latest generally available version of Sun Studio.

If not, I'll apply the patch manually tomorrow and try it that way...

Comment 35

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I can promise you that it won't be checked in tonight. I'm going to bed :-)

Comment 36

[Iain MacDonnell]

(In reply to comment #34)
> I've set it to use this compiler:
> 
> % CC -V
> CC: Sun C++ 5.5 Patch 113817-08 2004/04/13
> % 

I was able to reproduce the problem with this compiler. I then applied Roland's
patch and resumed the build, which completed successfully, so the patch looks
good to me (caveat being that it the early access Sun Studio 9 won't be supported)

Comment 37

[Boris Zbarsky [:bzbarsky]]

timeless checked in that patch on May 17.  Is this still an issue?

Comment 38

[Iain MacDonnell]

(In reply to comment #37)
> timeless checked in that patch on May 17.  Is this still an issue?

I'm about 97% sure it's fixed, but just set off a fresh trunk build with the
5.5 compiler to confirm - it'll take a few hours...

Comment 39

[Iain MacDonnell]

(In reply to comment #38)

Confirmed that the trunk now builds cleanly with "Sun C++ 5.5 Patch 113817-08
2004/04/13"

Comment 40

[Roland Mainz]

Iain MacDonnell wrote:
> Confirmed that the trunk now builds cleanly with "Sun C++ 5.5 Patch 113817-08
> 2004/04/13"

Thanks.
It seems to work now even with older versions than 5.5 :)

Comment 41

[Roland Mainz]

Marking bug as FIXED.

roc:
Are there any plans to checkin the patch which caused this issue into to the 1.7
or aviary(sp?) branches ?

Comment 42

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I don't have any plans. If you think that's a good idea, set the 1.7? request
flag and do whatever has to be done to request checkin for aviary.