316859 - undefined symbol in components/libhtmlpars.so

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Peter Müller]

User-Agent:       Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.9a1) Gecko/20051110 SeaMonkey/1.5a
Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.9a1) Gecko/20051110 SeaMonkey/1.5a

% ./seamonkey-bin

ld.so.1: seamonkey-bin: fatal: relocation error: file /soft/mozilla/mozilla/dist/seamonkey/components/libhtmlpars.so: symbol __1cRAppendUCS4ToUTF166FkIrnSnsAString_internal__v_: referenced symbol not found
Killed


Reproducible: Always

Steps to Reproduce:
1. Build an actual trunk (> 20051114)
2. Start SeaMonkey
3. -> Crash




Compiler: Sun Studio 10 (v5.7) and 11 (v5.8)

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

don't run seamonkey-bin directly, run ./seamonkey

Comment 2

[Peter Müller]

(In reply to comment #1)
> don't run seamonkey-bin directly, run ./seamonkey
> 

(In reply to comment #1)
> don't run seamonkey-bin directly, run ./seamonkey
> 
This is definitely not the problem, it is the way
i'm running seamonkey for ages and until Nov 15 the way it
worked ...

BTW, same behaviour on Solaris x86 (PC) since Nov 15.
PM

Comment 3

[Peter Müller]

> 
> BTW, same behaviour on Solaris x86 (PC) since Nov 15.
> PM
> 

last working build on x86 I have: 2005111519

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

_does_ ./seamonkey work?

Comment 5

[Peter Müller]

(In reply to comment #4)
> _does_ ./seamonkey work?
> 

no, same crash behaviour

Comment 6

[Boris Zbarsky [:bzbarsky]]

Odd.  Doesn't parser link to xpcom as needed?  The function is declared in xpcom/string/public/nsReadableUtils.h and implemented in xpcom/string/src/nsReadableUtils.cpp, and uses NS_COM, so all should be ok....  The parser file in question does include nsReadableUtils.h.

Comment 7

[Peter Müller]

Similar on actual thunderbird trunks, but here with compile/build error:

% CC -o thunderbird-bin ... -lxpcom_compat

Undefined                       first referenced
 symbol                             in file
void AppendUCS4ToUTF16(const unsigned,nsAString_internal&) ../../dist/lib/components/libhtmlpars.a(nsHTMLTokens.o)
ld: fatal: Symbol referencing errors. No output written to thunderbird-bin
gmake[5]: *** [thunderbird-bin] Error 1

Comment 8

[Boris Zbarsky [:bzbarsky]]

That's really odd.  So what's Solaris doing differently from everything else here?  This code compiles and runs fine on Mac/Linux/Windows/AIX...

Comment 9

[Peter Müller]

(In reply to comment #8)
> That's really odd.  So what's Solaris doing differently from everything else
> here?  This code compiles and runs fine on Mac/Linux/Windows/AIX...
> 
Some observations:

% nm ./xpcom/string/src/nsReadableUtils.o | grep LossyCopyUTF16toASCII
[107]   |        64|     176|FUNC |GLOB |0    |2      |__1cVLossyCopyUTF16toASCII6FpkHrnTnsACString_internal__v_

i.e. defined ...

% nm ./parser/htmlparser/src/nsHTMLTokens.o | grep AppendUCS4ToUTF16    
[389]   |         0|       0|FUNC |GLOB |0    |UNDEF  |__1cRAppendUCS4ToUTF166FkIrnSnsAString_internal__v_

here undefined!

So the AppendUCS4ToUTF16 definition in components/libhtmlpars.so 
comes not from nsReadableUtils.o but from nsHTMLTokens.o ...

Comment 10

[Peter Müller]

(In reply to comment #9)
> 
> % nm ./xpcom/string/src/nsReadableUtils.o | grep LossyCopyUTF16toASCII
> [107]   |        64|     176|FUNC |GLOB |0    |2     
> |__1cVLossyCopyUTF16toASCII6FpkHrnTnsACString_internal__v_
> 

Sorry, this should be:

nm ./xpcom/string/src/nsReadableUtils.o | grep AppendUCS4ToUTF16    
[155]   |      8484|     120|FUNC |GLOB |0    |2      |__1cRAppendUCS4ToUTF166FIrnSnsAString_internal__v_

Comment 11

[Peter Müller]

(In reply to comment #9)

> 
> So the AppendUCS4ToUTF16 definition in components/libhtmlpars.so 
> comes not from nsReadableUtils.o but from nsHTMLTokens.o ...
> 

... introduced in nsHTMLTokens.cpp, Version 3.278, line 2366:
...
  AppendUCS4ToUTF16(ENSURE_VALID_CHAR(aNCRValue), aString);
...

Comment 12

[Peter Müller]

(In reply to comment #11)

> 
> ... introduced in nsHTMLTokens.cpp, Version 3.278, line 2366:
> ...
>   AppendUCS4ToUTF16(ENSURE_VALID_CHAR(aNCRValue), aString);
> ...
> 

furher 'infected': layout/style/nsCSSScanner.cpp

OK, after reverting nsHTMLTokens.cpp to v3.277 and 
and nsCSSScanner.cpp to v3.82 (only the AppendUCS4ToUTF16 part!,
lines 879-883 in v3.83) I was able to build thunderbird again
and it's running (but this is (not a| a durty) solution :-(

Comment 13

[Peter Müller]

(In reply to comment #12)
>
> I was able to build thunderbird again
> and it's running (but this is (not a| a durty) solution :-(
> 

Same with seamonkey, now I'm runnig Build ID:2005111814

Comment 14

[Boris Zbarsky [:bzbarsky]]

> ... introduced in nsHTMLTokens.cpp, Version 3.278, line 2366:

Yes, I'm well aware of that -- I added it.

Again:

1)  nsHTMLTokens.cpp includes nsReadableUtils.h, which defines this method.
2)  nsReadableUtils.cpp has an implementation of this method.
3)  nsHTMLTokens.cpp uses the method.

So why does this not work on Solaris, exactly?  Note that of course nm shows the method as undefined in nsHTMTokens.o; the whole point is that it's in a different module, but we link against it.

Comment 15

[Andrew Schultz]

==> parser

Comment 16

[Greg Onufer]

% nm libxpcom_core.so components/libhtmlpars.so | grep AppendUCS4ToUTF16
[5601]  |    873080|     100|FUNC |GLOB |0    |8      |__1cRAppendUCS4ToUTF166FIrnSnsAString_internal__v_
[1994]  |         0|       0|FUNC |GLOB |0    |UNDEF  |__1cRAppendUCS4ToUTF166FkIrnSnsAString_internal__v_

They're not the same symbol, the mangled names are different.

Comment 17

[Boris Zbarsky [:bzbarsky]]

Aha!  That's useful!

What do the demangled versions of those look like on your system?

Comment 18

[Peter Müller]

(In reply to comment #16)
> % nm libxpcom_core.so components/libhtmlpars.so | grep AppendUCS4ToUTF16
> [5601]  |    873080|     100|FUNC |GLOB |0    |8     
> |__1cRAppendUCS4ToUTF166FIrnSnsAString_internal__v_

--> ./xpcom/string/src/nsReadableUtils.o (s. above)

> [1994]  |         0|       0|FUNC |GLOB |0    |UNDEF 
> |__1cRAppendUCS4ToUTF166FkIrnSnsAString_internal__v_

--> ./parser/htmlparser/src/nsHTMLTokens.o (dito)

Comment 19

[Greg Onufer]

Attachment: patch

I finally have a successful trunk build with this change.  The definition of AppendUCS4ToUTF16 did not match the prototype.

Comment 20

[Christian :Biesinger (don't email me, ping me on IRC)]

heh, nice. why does this work on other compilers?

Comment 21

[Peter Müller]

(In reply to comment #19)
> Created an attachment (id=203626) [edit]
> patch
> 
> I finally have a successful trunk build with this change.  The definition of
> AppendUCS4ToUTF16 did not match the prototype.
> 

.. that simple ;-), thanks ...

Comment 22

[Boris Zbarsky [:bzbarsky]]

Checked in the fix.  Greg, thanks for tracking this down!

Comment 23

[Boris Zbarsky [:bzbarsky]]

Gah.  We forgot to track this regression...  We need this on branch.

Comment 24

[Daniel Veditz [:dveditz]]

nominating for blocking in case we re-spin (likely, just on general principal) but I think we wouldn't respin just for this. The people with compilers who need it can apply it by hand, or we can get this into the seamonkey release tag and they can pull by that.

But realistically we'll end up respinning for something else and can then take this.

Comment 25

[Daniel Veditz [:dveditz]]

Comment on attachment 203626 [details] [diff] [review]
patch

We're respinning, please land this bug on both the regular MOZILLA_1_8_BRANCH for 1.8.1.18 as well as the release mini-branch for 1.8.1.17:  GECKO181_20080827_RELBRANCH_REAL

Approved for 1.8.1.17 and 1.8.1.18, a=dveditz for release-drivers

Comment 26

[Daniel Veditz [:dveditz]]

Not blocking 1.8.1.17. Unfortunately short notice, but if it doesn't make it in during this window before we re-spin then it's not going to make it.

Comment 27

[Boris Zbarsky [:bzbarsky]]

Landed on GECKO181_20080827_RELBRANCH_REAL and MOZILLA_1_8_BRANCH.

Comment 28

[jnoyes-sf]

Unfortunately this was missed, didn't land on the SEAMONKEY_1_1_12_RELEASE tag, and broke the contrib builds for Solaris using the source release tarball.

Luckily, both contrib builders (myself and Bernd Senf) for Solaris tracked down the issue and applied the patch by hand for this contrib release.  It's not necessary to re-build the 1.1.12 release tarball.

Because the fix is in place on GECKO181_20080827_RELBRANCH_REAL and MOZILLA_1_8_BRANCH it won't come back for SM 1.1.13+

Comment 29

[Boris Zbarsky [:bzbarsky]]

> Unfortunately this was missed, didn't land on the SEAMONKEY_1_1_12_RELEASE tag,

Uh, I didn't realize the branch involved was cut from one of the two branches in comment 27 before checkin.  Someone should have spoken up at the time...

Comment 31

[Alexander Sack]

Comment on attachment 203626 [details] [diff] [review]
patch

a=asac for 1.8.0