undefined symbol in components/libhtmlpars.so

RESOLVED FIXED

Status

()

Core
XPCOM
--
critical
RESOLVED FIXED
12 years ago
9 years ago

People

(Reporter: Peter Müller, Assigned: Greg Onufer)

Tracking

({fixed1.8.1.17, fixed1.8.1.18, regression})

Trunk
Sun
Solaris
fixed1.8.1.17, fixed1.8.1.18, regression
Points:
---
Bug Flags:
blocking1.8.1.18 +
wanted1.8.1.x +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
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)
(Reporter)

Updated

12 years ago
Version: unspecified → Trunk
don't run seamonkey-bin directly, run ./seamonkey
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → INVALID
(Reporter)

Comment 2

12 years ago
(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
(Reporter)

Comment 3

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

last working build on x86 I have: 2005111519
_does_ ./seamonkey work?
(Reporter)

Comment 5

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

no, same crash behaviour
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Summary: Crash at start on components/libhtmlpars.so → undefined symbol in components/libhtmlpars.so
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.
(Reporter)

Comment 7

12 years ago
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
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...
(Reporter)

Comment 9

12 years ago
(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 ...
(Reporter)

Comment 10

12 years ago
(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_


(Reporter)

Comment 11

12 years ago
(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);
...
(Reporter)

Comment 12

12 years ago
(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 :-(
(Reporter)

Comment 13

12 years ago
(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
> ... 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

12 years ago
==> parser
Assignee: general → mrbkap
Component: General → HTML: Parser
Product: Mozilla Application Suite → Core
QA Contact: general → parser
(Assignee)

Comment 16

12 years ago
% 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.
Aha!  That's useful!

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

Comment 18

12 years ago
(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)
(Assignee)

Comment 19

12 years ago
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.
heh, nice. why does this work on other compilers?
Assignee: mrbkap → dougt
Status: UNCONFIRMED → NEW
Component: HTML: Parser → XPCOM
Ever confirmed: true
QA Contact: parser → xpcom
(Reporter)

Comment 21

12 years ago
(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 ...
Assignee: dougt → gonufer
Attachment #203626 - Flags: superreview+
Attachment #203626 - Flags: review+
Checked in the fix.  Greg, thanks for tracking this down!
Status: NEW → RESOLVED
Last Resolved: 12 years ago12 years ago
Resolution: --- → FIXED
Gah.  We forgot to track this regression...  We need this on branch.
Blocks: 316394
Attachment #203626 - Flags: approval1.8.1.17?
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.
Flags: wanted1.8.1.x+
Flags: blocking1.8.1.18?
Flags: blocking1.8.1.17?
Keywords: regression
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
Attachment #203626 - Flags: approval1.8.1.18+
Attachment #203626 - Flags: approval1.8.1.17?
Attachment #203626 - Flags: approval1.8.1.17+
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.
Flags: blocking1.8.1.18?
Flags: blocking1.8.1.18+
Flags: blocking1.8.1.17?
Landed on GECKO181_20080827_RELBRANCH_REAL and MOZILLA_1_8_BRANCH.
Keywords: fixed1.8.1.17, fixed1.8.1.18

Comment 28

9 years ago
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+
> 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...
Duplicate of this bug: 457283

Updated

9 years ago
Attachment #203626 - Flags: approval1.8.0.next?

Updated

9 years ago
Attachment #203626 - Flags: approval1.8.0.next? → approval1.8.0.next+

Comment 31

9 years ago
Comment on attachment 203626 [details] [diff] [review]
patch

a=asac for 1.8.0
You need to log in before you can comment on or make changes to this bug.