200965 - regchrome seg faults on alpha linux when compiled with -O2

Status: RESOLVED INVALID

(Core :: XPCOM, defect)

Description

[jt.marsh]

User-Agent:       Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.4a) Gecko/20030405
Build Identifier: 

+
LD_LIBRARY_PATH=/var/tmp/mozilla-root/usr/lib/mozilla-1.4a:/var/tmp/mozilla-root/usr/lib/mozilla-1.4a/..
++ pwd
+ MOZILLA_FIVE_HOME=/var/tmp/mozilla-root/usr/lib/mozilla-1.4a
+ ./regchrome
/var/tmp/rpm-tmp.74096: line 163: 15498 Segmentation fault      (core dumped)
LD_LIBRARY_PATH=`pwd`:`pwd`/.. MOZILLA_FIVE_HOME=`pwd` ./regchrome
error: Bad exit status from /var/tmp/rpm-tmp.74096 (%install)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.74096 (%install)


Reproducible: Always

Steps to Reproduce:
rpm -bb SPECFILE
Actual Results:  
regchrome seg faults

Same thing with the 1.3 release. 1.2.1 was the last successful build for me.


(gdb) where
#0  0x2000089ab84 in nsRDFXMLSerializer::SerializePrologue ()
   from /var/tmp/mozilla-root/usr/lib/mozilla-1.4a/components/librdf.so
#1  0x2000089b2e0 in nsRDFXMLSerializer::Serialize ()
   from /var/tmp/mozilla-root/usr/lib/mozilla-1.4a/components/librdf.so
#2  0x20000896000 in RDFXMLDataSourceImpl::Serialize ()
   from /var/tmp/mozilla-root/usr/lib/mozilla-1.4a/components/librdf.so
#3  0x20000894fc0 in RDFXMLDataSourceImpl::rdfXMLFlush ()
   from /var/tmp/mozilla-root/usr/lib/mozilla-1.4a/components/librdf.so
#4  0x2000089537c in RDFXMLDataSourceImpl::Flush ()
   from /var/tmp/mozilla-root/usr/lib/mozilla-1.4a/components/librdf.so
#5  0x2000054277c in nsChromeRegistry::WriteInfoToDataSource ()
   from /var/tmp/mozilla-root/usr/lib/mozilla-1.4a/components/libchrome.so
#6  0x20000542d20 in nsChromeRegistry::UpdateDynamicDataSource ()
   from /var/tmp/mozilla-root/usr/lib/mozilla-1.4a/components/libchrome.so
#7  0x20000543234 in nsChromeRegistry::UpdateDynamicDataSources ()
   from /var/tmp/mozilla-root/usr/lib/mozilla-1.4a/components/libchrome.so
#8  0x20000546bc4 in nsChromeRegistry::InstallProvider ()
   from /var/tmp/mozilla-root/usr/lib/mozilla-1.4a/components/libchrome.so
#9  0x2000054c5c4 in nsChromeRegistry::InstallPackage ()
   from /var/tmp/mozilla-root/usr/li#10 0x20000550da0 in
nsChromeRegistry::ProcessNewChromeBuffer ()
   from /var/tmp/mozilla-root/usr/lib/mozilla-1.4a/components/libchrome.so
#11 0x2000055030c in nsChromeRegistry::CheckForNewChrome ()
---Type <return> to continue, or q <return> to quit--- 
   from /var/tmp/mozilla-root/usr/lib/mozilla-1.4a/components/libchrome.so
#12 0x2000053a4d4 in nsChromeRegistry::Init ()
   from /var/tmp/mozilla-root/usr/lib/mozilla-1.4a/components/libchrome.so
#13 0x200005388b8 in nsChromeRegistryConstructor ()
   from /var/tmp/mozilla-root/usr/lib/mozilla-1.4a/components/libchrome.so
#14 0x20000148ad8 in nsGenericFactory::CreateInstance ()
   from /var/tmp/mozilla-root/usr/lib/mozilla-1.4a/libxpcom.so
#15 0x200000f808c in nsComponentManagerImpl::CreateInstanceByContractID ()
   from /var/tmp/mozilla-root/usr/lib/mozilla-1.4a/libxpcom.so
#16 0x200000f9054 in nsComponentManagerImpl::GetServiceByContractID ()
   from /var/tmp/mozilla-root/usr/lib/mozilla-1.4a/libxpcom.so
#17 0x2000014ab8c in nsGetServiceByContractID::operator() ()
   from /var/tmp/mozilla-root/usr/lib/mozilla-1.4a/libxpcom.so
#18 0x20000147f18 in nsCOMPtr_base::assign_from_helper ()
   from /var/tmp/mozilla-root/usr/lib/mozilla-1.4a/libxpcom.so
#19 0x120000c48 in main ()

Comment 1

[Andrew Schultz]

I had the same problem with Red Hat 7.2
compile nsRDFXMLSerializer.cpp with "-fno-strict-aliasing" and it works.

there's a similar problem somewhere in layout/xul/... but I don't remember the
specifics.  I gave up and compiled everything "-O"

==> rdf
marking NEW

Comment 2

[Andrew Schultz]

Alpha = DEC

Comment 3

[Henrik Gemal]

->rdf

Comment 4

[Andrew Schultz]

Attachment: stacktrace with more symbols

compiled nsRDFXMLSerializer (Mozilla 1.3) with "-O -fstrict-aliasing
-frerun-cse-after-loop"
frame 0 is actually nsRDFXMLSerializer.cpp:909:

	if (entry->mPrefix) {
	    rdf_BlockingWrite(aStream, NS_LITERAL_STRING(":"));
	    nsAutoString prefix;
	    entry->mPrefix->ToString(prefix);	 <== here
	    rdf_BlockingWrite(aStream, prefix);
	}

compiling with -fno-inline didn't crash.

Comment 5

[jt.marsh]

I don't know if this is related or not, but...

I compiled everything using -O, and that worked, but now XUL.mfasl gets hosed so
that when I startup Mozilla a second time, I have no bookmarks and no pulldown
menus.

Comment 6

[Andrew Schultz]

that's bug 184204

Comment 7

[Henrik Gemal]

since there's no QA on RDF I can't remove reassign it...
QA = [e-mail]

Comment 8

[Andrew Schultz]

Attachment: somewhat reduced testcase

this is a hacked version of nsRDFXMLSerializer::SerializePrologue that exhibits
this bug.  needs to be linked against xpcom, nspr4, plds4 and plc4.

output compiled with -O:
1
2

output compiled with -O2:
1
Seg fault

as before, -fno-strict-aliasing fixes the -O2 case

Comment 9

[Andrew Schultz]

this doesn't look like an RDF problem (unless it's using nsAtoms improperly, or
nsNameSpace is screwed up), and it's doing nothing but rot in RDF.

==> XPCOM

also, I had been using gcc 2.96-112, which is the most up-to-date gcc from Red
Hat (HP) for Alpha.  7.2 also comes with gcc3 (3.0.4).  using that, the testcase
works fine.  I'm rebuilding everything else to see if gcc3 fixes regchrome as well.

Comment 10

[Andrew Schultz]

XPCOM

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

In the debugger, can you look and see what fooEntry.mCurrent,
fooEntry.mCurrent->mPrefix, etc., are, to see what exactly it's crashing on?

Comment 12

[Andrew Schultz]

I just rebuilt with gcc3 and regchrome works.
I'll try out the debugger tomorrow.

Comment 13

[Andrew Schultz]

with -O2
fooFirst = {mCurrent = 0x12001bd20}
fooLast = {mCurrent = 0x12001bd20}
fooEntry = {mCurrent = 0x20000176400}
fooEntry.mCurrent->mPrefix = {<nsCOMPtr_base> = {mRawPtr = 0x0}, <No data fields>

with -O2 -fno-strict-aliasing
fooFirst = {mCurrent = 0x12001bd20}
fooLast = {mCurrent = 0x12001bd20}
fooEntry = {mCurrent = 0x12001bd20}
fooEntry.mCurrent->mPrefix = {<nsCOMPtr_base> = {mRawPtr = 0x12001bd00}, <No
data fields>}

looks like "fooEntry = fooFirst" is busted

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Does the patch in bug 212082 help?  (With what version of gcc do you see the
problem?  You might need to change the ifdefs or make the change unconditional
if it's less than 3.)

Comment 15

[Andrew Schultz]

> Does the patch in bug 212082 help?

I hoped the same, but tried it out last month with no change in behavior.

> with what version of gcc do you see the problem? 

only gcc296 (3.0.4 works).  I just defined NSCAP_FEATURE_DEBUG_PTR_TYPES
unconditionally.

Comment 16

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Maybe a bug in 2.96?  2.96 was never an official release, after all.

Comment 17

[falk]

I cannot reproduce this with the reduced test case and gcc 3.3. I guess it has
been fixed by the pointer aliasing fixes. I recommend closing this bug.

Comment 18

[Andrew Schultz]

right.  gcc3.0 worked for me as well.

resolving INVALID... this was probably a gcc bug and/or it's not worth working
around.