Last Comment Bug 316859 - undefined symbol in components/libhtmlpars.so
: undefined symbol in components/libhtmlpars.so
Status: RESOLVED FIXED
: fixed1.8.1.17, fixed1.8.1.18, regression
Product: Core
Classification: Components
Component: XPCOM (show other bugs)
: Trunk
: Sun Solaris
: -- critical (vote)
: ---
Assigned To: Greg Onufer
:
:
Mentors:
: 457283 (view as bug list)
Depends on:
Blocks: 316394
  Show dependency treegraph
 
Reported: 2005-11-17 07:46 PST by Peter Müller
Modified: 2009-02-09 11:14 PST (History)
9 users (show)
dveditz: blocking1.8.1.18+
dveditz: wanted1.8.1.x+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch (681 bytes, patch)
2005-11-19 01:39 PST, Greg Onufer
bzbarsky: review+
bzbarsky: superreview+
dveditz: approval1.8.1.17+
dveditz: approval1.8.1.18+
asac: approval1.8.0.next+
Details | Diff | Splinter Review

Description Peter Müller 2005-11-17 07:46:36 PST
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) 2005-11-17 08:16:34 PST
don't run seamonkey-bin directly, run ./seamonkey
Comment 2 Peter Müller 2005-11-17 08:23:18 PST
(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 2005-11-17 08:36:33 PST
> 
> 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) 2005-11-17 09:08:56 PST
_does_ ./seamonkey work?
Comment 5 Peter Müller 2005-11-17 09:23:21 PST
(In reply to comment #4)
> _does_ ./seamonkey work?
> 

no, same crash behaviour
Comment 6 Boris Zbarsky [:bz] (still a bit busy) 2005-11-17 14:48:19 PST
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 2005-11-17 22:43:12 PST
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 [:bz] (still a bit busy) 2005-11-17 23:02:16 PST
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 2005-11-18 00:29:37 PST
(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 2005-11-18 00:31:59 PST
(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 2005-11-18 03:44:38 PST
(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 2005-11-18 04:48:42 PST
(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 2005-11-18 05:17:05 PST
(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 [:bz] (still a bit busy) 2005-11-18 07:22:12 PST
> ... 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 2005-11-18 19:48:57 PST
==> parser
Comment 16 Greg Onufer 2005-11-18 22:02:26 PST
% 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 [:bz] (still a bit busy) 2005-11-18 22:11:13 PST
Aha!  That's useful!

What do the demangled versions of those look like on your system?
Comment 18 Peter Müller 2005-11-19 01:26:50 PST
(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 2005-11-19 01:39:43 PST
Created attachment 203626 [details] [diff] [review]
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) 2005-11-19 04:50:54 PST
heh, nice. why does this work on other compilers?
Comment 21 Peter Müller 2005-11-19 05:25:39 PST
(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 [:bz] (still a bit busy) 2005-11-20 11:38:47 PST
Checked in the fix.  Greg, thanks for tracking this down!
Comment 23 Boris Zbarsky [:bz] (still a bit busy) 2008-08-28 09:54:21 PDT
Gah.  We forgot to track this regression...  We need this on branch.
Comment 24 Daniel Veditz [:dveditz] 2008-08-28 10:20:37 PDT
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] 2008-08-28 16:40:52 PDT
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] 2008-08-28 16:45:30 PDT
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 [:bz] (still a bit busy) 2008-08-28 17:41:12 PDT
Landed on GECKO181_20080827_RELBRANCH_REAL and MOZILLA_1_8_BRANCH.
Comment 28 jnoyes-sf 2008-09-29 02:38:09 PDT
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 [:bz] (still a bit busy) 2008-09-29 05:44:46 PDT
> 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 30 Benjamin Smedberg [:bsmedberg] 2008-09-29 07:56:09 PDT
*** Bug 457283 has been marked as a duplicate of this bug. ***
Comment 31 Alexander Sack 2009-02-09 11:14:07 PST
Comment on attachment 203626 [details] [diff] [review]
patch

a=asac for 1.8.0

Note You need to log in before you can comment on or make changes to this bug.