Last Comment Bug 613374 - [SeaMonkey 2.0, nightlies] new OTS code causes "gfxUserFontSet.cpp:281: undefined reference to `ots::Process(ots::OTSStream*, unsigned char const*, unsigned int, bool)'"
: [SeaMonkey 2.0, nightlies] new OTS code causes "gfxUserFontSet.cpp:281: undef...
Status: RESOLVED FIXED
: verified1.9.1
Product: Core
Classification: Components
Component: Graphics (show other bugs)
: 1.9.1 Branch
: All All
: -- blocker (vote)
: ---
Assigned To: Justin Wood (:Callek) (Away until Aug 29)
:
Mentors:
Depends on:
Blocks: CVE-2010-3768 615196
  Show dependency treegraph
 
Reported: 2010-11-18 15:51 PST by Serge Gautherie (:sgautherie)
Modified: 2010-12-10 09:21 PST (History)
7 users (show)
bugzillamozillaorg_serge_20140323: in‑testsuite-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
unaffected
unaffected
.16-fixed


Attachments
c-c part (1.17 KB, patch)
2010-11-20 07:55 PST, Justin Wood (:Callek) (Away until Aug 29)
bugspam.Callek: review+
Details | Diff | Splinter Review
m-c part (356 bytes, patch)
2010-11-20 07:55 PST, Justin Wood (:Callek) (Away until Aug 29)
standard8: review+
khuey: review+
dveditz: approval1.9.1.16+
dveditz: approval1.9.1.17+
Details | Diff | Splinter Review

Description Serge Gautherie (:sgautherie) 2010-11-18 15:51:51 PST
Johathan:
Passing t-b: "build" and "unit test".
Failing t-b: "nightly".

Robert:
"Unexpectedly", 'Linux x86-64 comm-1.9.1 build' fails too.
Comment 1 Serge Gautherie (:sgautherie) 2010-11-18 17:24:51 PST
(In reply to comment #0)
> Robert:
> "Unexpectedly", 'Linux x86-64 comm-1.9.1 build' fails too.

Fwiw, dep/mozconfig are the same for Linux and Linux64.
Comment 2 Robert Kaiser 2010-11-18 18:34:46 PST
The passing ones might just be because they don't clobber, while nightlies always clobber.
Comment 3 Robert Kaiser 2010-11-19 06:24:20 PST
Neil, Justin, Mark, may this be connected with not using libxul on the 1.9.1 branch? Do you have any ideas how to fix this? We'd like to go for building another security update for SeaMonkey 2.0.x soon, but we'd need it to compile for that...
Comment 4 Mark Banner (:standard8) 2010-11-19 08:02:34 PST
It always helps to include a brief log...

The nightly builds are failing with:

../../mozilla/staticlib/libthebes.a(gfxUserFontSet.o): In function `gfxUserFontSet::OnLoadComplete(gfxFontEntry*, unsigned char const*, unsigned int, unsigned int)':
/builds/slave/comm-1.9.1-linux-nightly/build/mozilla/gfx/thebes/src/gfxUserFontSet.cpp:281: undefined reference to `ots::Process(ots::OTSStream*, unsigned char const*, unsigned int, bool)'
collect2: ld returned 1 exit status

whilst linking seamonkey-bin

The linux 64 bit build is failing with:

/usr/bin/ld: gfxUserFontSet.o: relocation R_X86_64_PC32 against `ots::Process(ots::OTSStream*, unsigned char const*, unsigned long, bool)' can not be used when making a shared object; recompile with -fPIC

and this is linking thebes.

So nightly versus dep is different... what does SeaMonkey do different in terms of build configuration? nightly are static, dep are shared.

Once you know that, its slightly more obvious that the nightly bustage is due to not linking something into seamonkey-bin, and given where gfxUserFontSet.cpp is I'd bet that's not being linked against the thebes library.

The Thunderbird part of the puzzle is caused by the fact that on comm-1.9.1 Thunderbird dep & nightly builds get fixed to a specific revision until the next release, so I suspect when we hit that we'll get the issues SM is seeing as Thunderbird doesn't link against thebes at the moment either.


Swapping to the linux 64 bit issue, that is typically just needing a FORCE_USE_PIC=1 put in an appropriate makefile.in - probably the thebes/src/Makefile.in.
Comment 5 Justin Wood (:Callek) (Away until Aug 29) 2010-11-19 20:59:06 PST
I'm testing a patch for static builds atm, have not yet written or tested a patch for linux64.
Comment 6 Justin Wood (:Callek) (Away until Aug 29) 2010-11-20 07:55:22 PST
Created attachment 492065 [details] [diff] [review]
c-c part

This ports bug 527276 and adds the lib to static-config.mk as well.
Comment 7 Justin Wood (:Callek) (Away until Aug 29) 2010-11-20 07:55:59 PST
Created attachment 492066 [details] [diff] [review]
m-c part

add the lib to static-config.mk in m-c too
Comment 8 Justin Wood (:Callek) (Away until Aug 29) 2010-11-20 07:57:11 PST
(In reply to comment #6)
> c-c part

(In reply to comment #7)
> m-c part

c-191 and m-191 actually.

And everything built and linked fine in my test with both these patches
Comment 9 Justin Wood (:Callek) (Away until Aug 29) 2010-11-20 18:56:08 PST
Comment on attachment 492066 [details] [diff] [review]
m-c part

requesting approval for this part now. Its safe, not used for Firefox and fixes SeaMonkey and Thunderbird builds, so that we can have nightlies and have a release ready for the next security drill.

khuey is official reviewer, Mark is requested but not official for the m-c part here, its just a formality for this bug as a whole.
Comment 10 Mark Banner (:standard8) 2010-11-22 06:15:20 PST
Comment on attachment 492065 [details] [diff] [review]
c-c part

Not tested this but it looks fine. a=Standard8 for 1.9.1 landing as well.
Comment 11 Daniel Veditz [:dveditz] 2010-11-22 10:13:54 PST
Comment on attachment 492066 [details] [diff] [review]
m-c part

Approved for 1.9.1.17, a=dveditz for release-drivers. I assume we'll want to land this on the _RELBRANCH so it makes the 1.9.1.16-based releases.

Won't we want this on the 1.9.2 branch for Thunderbird 3.2 as well?
Comment 12 christian 2010-11-22 10:17:23 PST
FYI, the relbranch is GECKO19116_20101122_RELBRANCH.
Comment 13 Mark Banner (:standard8) 2010-11-22 10:33:12 PST
(In reply to comment #11)
> Won't we want this on the 1.9.2 branch for Thunderbird 3.2 as well?

No, I believe I fixed Thunderbird 3.1 (probably by a different route) a while ago.
Comment 14 Daniel Veditz [:dveditz] 2010-11-22 12:04:45 PST
Just to clarify comment 11 and 12: please _do_ land on GECKO19116_20101122_RELBRANCH and base your builds on that changeset. If we end up taking additional fixes Firefox will pick it up, and if not it we'll still have code-level compatibility on this release.
Comment 15 Justin Wood (:Callek) (Away until Aug 29) 2010-11-22 19:59:58 PST
(In reply to comment #11)
> Comment on attachment 492066 [details] [diff] [review]
> m-c part
> 
> Approved for 1.9.1.17, a=dveditz for release-drivers.

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/3b74f6a6bc71

> I assume we'll want to
> land this on the _RELBRANCH so it makes the 1.9.1.16-based releases.

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/54745ba055f0

> Won't we want this on the 1.9.2 branch for Thunderbird 3.2 as well?

If any of those here want a 1.9.2 patch to sync it and be "safe" there, I'm happy to provide it.

(In reply to comment #10)
> Comment on attachment 492065 [details] [diff] [review]
> c-c part
> 
> Not tested this but it looks fine. a=Standard8 for 1.9.1 landing as well.

http://hg.mozilla.org/releases/comm-1.9.1/rev/0c235bd0797a

(setting status2.0 to unaffected, but really its wontfix)
Comment 16 Serge Gautherie (:sgautherie) 2010-11-22 20:39:40 PST
(In reply to comment #13)
> I fixed Thunderbird 3.1 (probably by a different route) a while ago.

Bug 527276 comment 82 ;->
Comment 17 Serge Gautherie (:sgautherie) 2010-11-22 21:46:15 PST
(In reply to comment #2)
> The passing ones might just be because they don't clobber, while nightlies
> always clobber.

Hum...

According to (new) SM Clobberer page, no SM 2.0 build was clobbered that way yet :-|
This lets us wonder whether this is truly Linux64 specific or not.

Moreover, if this bug is clobber related, it would mean there is/was a dependency issue somewhere, wouldn't it?

I'm clobberring 'build' on cb-seamonkey-linux-02 and cb-seamonkey-linux64-01, fwiw: submitted at "2010-11-22 21:43:07 PST".
(This is also a check on my side as it's the first time I use this tool.)


(In reply to comment #4)
> Swapping to the linux 64 bit issue, that is typically just needing a
> FORCE_USE_PIC=1 put in an appropriate makefile.in - probably the
> thebes/src/Makefile.in.

This part remains to be fixed.
Comment 18 Justin Wood (:Callek) (Away until Aug 29) 2010-11-22 21:48:30 PST
(In reply to comment #17)
> (In reply to comment #2)
> > The passing ones might just be because they don't clobber, while nightlies
> > always clobber.
> 
> Hum...

> (In reply to comment #4)
> > Swapping to the linux 64 bit issue, that is typically just needing a
> > FORCE_USE_PIC=1 put in an appropriate makefile.in - probably the
> > thebes/src/Makefile.in.
> 
> This part remains to be fixed.

I want to spin it out to another bug, as it is two separate issues to fix (though both the same cause). I'll file at latest tomorrow.
Comment 19 Serge Gautherie (:sgautherie) 2010-11-22 21:50:45 PST
(In reply to comment #17)
> This lets us wonder whether this is truly Linux64 specific or not.

Fwiw, TB 'Linux x86-64 comm-1.9.2 check' is green.
Comment 20 Mark Banner (:standard8) 2010-11-23 00:45:31 PST
(In reply to comment #17)
> (In reply to comment #2)
> > The passing ones might just be because they don't clobber, while nightlies
> > always clobber.
> 
> Hum...
> 
> According to (new) SM Clobberer page, no SM 2.0 build was clobbered that way
> yet :-|
> This lets us wonder whether this is truly Linux64 specific or not.
> 
> Moreover, if this bug is clobber related, it would mean there is/was a
> dependency issue somewhere, wouldn't it?

Re-read my comment 4. The effect is caused by the dep/nightly builders on SeaMonkey having two different configurations.
Comment 21 Serge Gautherie (:sgautherie) 2010-11-23 02:04:45 PST
verified1.9.1, per
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey2.0/1290501537.1290504808.3890.gz
Linux x86-64 comm-1.9.1 nightly on 2010/11/23 00:38:57

*****

(In reply to comment #20)
> (In reply to comment #17)
> > Moreover, if this bug is clobber related, it would mean there is/was a
> > dependency issue somewhere, wouldn't it?
> 
> Re-read my comment 4. The effect is caused by the dep/nightly builders on
> SeaMonkey having two different configurations.

I'm not sure we're talking about the same thing:
I think I understood your comment 4,
but, in comment 17, I was wondering about Linux64 dep versus 3 other deps.
Comment 22 Serge Gautherie (:sgautherie) 2010-11-29 06:31:57 PST
(In reply to comment #17)

> I'm clobberring 'build' on cb-seamonkey-linux-02 and cb-seamonkey-linux64-01,
> fwiw: submitted at "2010-11-22 21:43:07 PST".

cb-seamonkey-linux-02:

http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey2.0/1290490267.1290494178.23268.gz&fulltext=1
Linux comm-1.9.1 build on 2010/11/22 21:31:07
free-space clobber
{
Checking clobber URL: ...
comm-1.9.1-linux:Our last clobber date:  None
comm-1.9.1-linux:Server clobber date:    None
TinderboxPrint: free-space clobber
}
started was just before I requested a clobber.

http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey2.0/1290515038.1290519161.23185.gz&fulltext=1
Linux comm-1.9.1 build on 2010/11/23 04:23:58
{
Checking clobber URL: ...
comm-1.9.1-linux:Our last clobber date:  2010-11-22 21:43:07
comm-1.9.1-linux:Server clobber date:    2010-11-22 21:43:07
}
should be the one to be clobbered.
Though it doesn't explicitly report clobbering anywhere, afaict.
(I thought "forced clobber" or something should be printed...)

cb-seamonkey-linux64-01:

http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey2.0/1290484640.1290484824.14401.gz&fulltext=1
Linux x86-64 comm-1.9.1 build on 2010/11/22 19:57:20
{
Checking clobber URL: ...
comm-1.9.1-linux64:Our last clobber date:  2010-11-20 03:53:27
comm-1.9.1-linux64:Server clobber date:    None
comm-central-trunk-linux64:Our last clobber date:  2010-11-15 21:33:20
comm-central-trunk-linux64:Server clobber date:    2010-11-08 20:30:00
}

http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey2.0/1290518787.1290519669.26174.gz&fulltext=1
Linux x86-64 comm-1.9.1 build on 2010/11/23 05:26:27
{
Checking clobber URL: ...
comm-1.9.1-linux64:Our last clobber date:  2010-11-22 21:43:07
comm-1.9.1-linux64:Server clobber date:    2010-11-22 21:43:07
comm-central-trunk-linux64:Our last clobber date:  2010-11-15 21:33:20
comm-central-trunk-linux64:Server clobber date:    2010-11-08 20:30:00
}

linux is still green, linux64 is still red:
either clobber didn't work or the issue is (confirmed as) linux64 specific.


(In reply to comment #18)

> I want to spin it out to another bug, as it is two separate issues to fix
> (though both the same cause). I'll file at latest tomorrow.

I eventually filed bug 615196.
Comment 23 Vincent S. Cojot 2010-12-10 09:21:35 PST
I just stumbled on this issue in seamonkey 2.0.11 on RHEL5.
All previous versions (2.0.x up to and including 2.0.10) did build and work fine as linux64. Something changed in 2.0.11 which is causing my rpmbuild to fail:

c++  -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-long-long -pedantic -fno-strict-aliasing -fshort-wchar -pthread -pipe  -DNDEBUG -DTRIMMED -Os -freorder-blocks -fno-reorder-functions -finline-limit=50 -I/usr/src/redhat/BUILD/seamonkey/objdir/mozilla/dist/include/cairo -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/gtk-unix-print-2.0   -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/freetype2   -fPIC -shared -Wl,-z,defs -Wl,-h,libthebes.so -o libthebes.so  cairo-xlib-utils.o gfxASurface.o gfxAlphaRecovery.o gfxBlur.o gfxContext.o gfxImageSurface.o gfxFont.o gfxFontMissingGlyphs.o gfxFontTest.o gfxFontUtils.o gfxMatrix.o gfxPath.o gfxPattern.o gfxPlatform.o gfxRect.o gfxSkipChars.o gfxTextRunCache.o gfxTextRunWordCache.o gfxUserFontSet.o gfxPangoFonts.o gfxXlibSurface.o gfxPlatformGtk.o gfxGdkNativeRenderer.o gfxPDFSurface.o gfxPSSurface.o gfxFontconfigUtils.o nsUnicodeRange.o     -lpthread   -Wl,-rpath-link,/usr/src/redhat/BUILD/seamonkey/objdir/mozilla/dist/bin -Wl,-rpath-link,/usr/lib  ../../../gfx/cairo/cairo/src/libmozcairo.a ../../../gfx/cairo/libpixman/src/libmozlibpixman.a   -L/usr/lib64 -lXrender -lfreetype -lfontconfig /usr/src/redhat/BUILD/seamonkey/objdir/mozilla/dist/lib/libunicharutil_s.a -L/usr/src/redhat/BUILD/seamonkey/objdir/mozilla/dist/bin -lxpcom -lxpcom_core  -L/usr/src/redhat/BUILD/seamonkey/objdir/mozilla/dist/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl -lz  ../../../gfx/qcms/libmozqcms.a ../../../gfx/ots/src/libmozots.a  -L/lib64 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0   -lz  -L/usr/lib64 -lX11  -L/lib64 -lgtk-x11-2.0 -latk-1.0 -lgdk-x11-2.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0    -lasound -ldl -lm
/usr/bin/ld: gfxUserFontSet.o: relocation R_X86_64_PC32 against `ots::Process(ots::OTSStream*, unsigned char const*, unsigned long, bool)' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
gmake[7]: *** [libthebes.so] Error 1
gmake[7]: Leaving directory `/usr/src/redhat/BUILD/seamonkey/objdir/mozilla/gfx/thebes/src'
gmake[6]: *** [libs] Error 2
gmake[6]: Leaving directory `/usr/src/redhat/BUILD/seamonkey/objdir/mozilla/gfx/thebes'
gmake[5]: *** [libs] Error 2
gmake[5]: Leaving directory `/usr/src/redhat/BUILD/seamonkey/objdir/mozilla/gfx'
gmake[4]: *** [libs_tier_gecko] Error 2
gmake[4]: Leaving directory `/usr/src/redhat/BUILD/seamonkey/objdir/mozilla'
gmake[3]: *** [tier_gecko] Error 2
gmake[3]: Leaving directory `/usr/src/redhat/BUILD/seamonkey/objdir/mozilla'
gmake[2]: *** [default] Error 2
gmake[2]: Leaving directory `/usr/src/redhat/BUILD/seamonkey/objdir/mozilla'
make[1]: *** [default] Error 2
make[1]: Leaving directory `/usr/src/redhat/BUILD/seamonkey/objdir'
make: *** [build] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.2979 (%build)

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