1533133 - Undefined symbol __stack_chk_fail first referenced in file ../../../mozglue/build/SSE.o

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Petr Sumbera]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0

Steps to reproduce:

This seems to be related to fix for Bug 1503589.

When building on Solaris I get:

/usr/bin/g++ -o ../../../dist/bin/js -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wall -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof -Wc++1z-compat -Wduplicated-cond -Wimplicit-fallthrough -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=free-nonheap-object -Wformat -Wformat-overflow=2 -Wno-noexcept-type -fno-sized-deallocation -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pthread -pipe -g -O -fno-omit-frame-pointer -funwind-tables @/builds/psumbera/FIREFOX-TRUNK/obj-x86_64-pc-solaris2.11/js/src/shell/js.list -lpthread -Wl,-z,text -rdynamic -L/builds/psumbera/FIREFOX-TRUNK/obj-x86_64-pc-solaris2.11/dist/bin ../build/libjs_static.a /builds/psumbera/FIREFOX-TRUNK/obj-x86_64-pc-solaris2.11/x86_64-sun-solaris/debug/libjsrust.a -pie ../../../config/external/nspr/pr/libnspr4.so ../../../config/external/nspr/libc/libplc4.so ../../../config/external/nspr/ds/libplds4.so -lm -lsocket -lz -lm -lposix4 -ldl -lnsl -lsocket

Undefined first referenced
symbol in file
__stack_chk_fail ../../../mozglue/build/SSE.o (symbol belongs to implicit dependency /usr/gcc/7/lib/gcc/x86_64-pc-solaris2.11/7.3.0/../../../amd64/libssp.so.0)
__stack_chk_guard ../../../mozglue/build/SSE.o (symbol belongs to implicit dependency /usr/gcc/7/lib/gcc/x86_64-pc-solaris2.11/7.3.0/../../../amd64/libssp.so.0)
ld: fatal: symbol referencing errors
collect2: error: ld returned 1 exit status
gmake[3]: *** [/builds/psumbera/FIREFOX-TRUNK/config/rules.mk:527: ../../../dist/bin/js] Error 1
gmake[3]: Leaving directory '/builds/psumbera/FIREFOX-TRUNK/obj-x86_64-pc-solaris2.11/js/src/shell'

I can fix that by adding '-lssp'.

Or not to use '-fstack-protector-strong'.

I wonder why it's not needed on Linux.

Comment 1

[Petr Sumbera]

I should have added that I use gcc.

Any idea please?

Comment 2

[Mike Hommey [:glandium]]

You probably need something like

--- a/build/moz.configure/toolchain.configure
+++ b/build/moz.configure/toolchain.configure
@@ -1683,6 +1683,7 @@ def security_hardening_cflags(hardening_flag, asan, optimize, c_compiler, target
             # mingw-clang cross-compile toolchain has bugs with stack protector
             if target.os != 'WINNT' or c_compiler == 'gcc':
                 flags.append("-fstack-protector-strong")
+                ldflags.append("-fstack-protector-strong")
 
         # ASLR ------------------------------------------------
         # ASLR (dynamicbase) is enabled by default in clang-cl; but the

Comment 3

[Petr Sumbera]

Actually I have to add also js_ldflags.append and then it worked:

--- a/build/moz.configure/toolchain.configure Tue Mar 05 23:26:52 2019 -0800
+++ b/build/moz.configure/toolchain.configure Thu Mar 07 08:40:36 2019 -0800
@@ -1682,6 +1682,8 @@
# mingw-clang cross-compile toolchain has bugs with stack protector
if target.os != 'WINNT' or c_compiler == 'gcc':
flags.append("-fstack-protector-strong")

•            ldflags.append("-fstack-protector-strong")
  

•            js_ldflags.append("-fstack-protector-strong")
  
     # ASLR ------------------------------------------------
     # ASLR (dynamicbase) is enabled by default in clang-cl; but the
  

Not sure whether we should add also js_flags.append("-fstack-protector-strong")?

Comment 4

[Alex Gaynor [:Alex_Gaynor]]

Redirecting to :gcp who looked at these recently.

Comment 5

[Gian-Carlo Pascutto [:gcp]]

Not sure what the needinfo is for? Adding it to the ldflags is fine if that turns out to be needed.

The situation with js_flags seems rather strange, I remember bug 1359905. If apparently the strong stack protector is being applied (and I'd guess due to do being carried over in flags[]?), what's the point of the js_flags logic then?

Comment 6

[Gian-Carlo Pascutto [:gcp]]

Attachment: Bug 1533133 - Fix missing linker and JS engine options for SSP. r=glandium

Comment 7

[Gian-Carlo Pascutto [:gcp]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=443cbcb6609930e646682c7123442eccc3611b1d

Comment 8

[Mike Hommey [:glandium]]

When -fstack-protector-strong was added, it was added in old-configure.in, not js/src/old-configure.in. I don't know if that was on purpose (maybe the JS engine doesn't like it?) or if it was an overlook. The logic in toolchain.configure was made to respect that setup.

Note the same is true of -fno-common.

Comment 9

[Gian-Carlo Pascutto [:gcp]]

This makes the Mac OS X debug JIT tests go reproducibly orange, but upon closer inspection they are timing out because of "runtime exceeded". In optimized mode they take 20 minutes right now, and in debug mode 59 minutes 48 seconds.

So, I don't think this is an actual problem...

Comment 10

[Gian-Carlo Pascutto [:gcp]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=13c7660bd17a3504d0be0ae9617d5148ee34a411

Comment 11

[Gian-Carlo Pascutto [:gcp]]

Attachment: Bug 1533133 - Split up macOS JIT tests in more chunks. r=jmaher

Depends on D22730

Comment 12

[Gian-Carlo Pascutto [:gcp]]

When -fstack-protector-strong was added, it was added in old-configure.in, not js/src/old-configure.in. I don't know if that was on purpose (maybe the JS engine doesn't like it?) or if it was an overlook. The logic in toolchain.configure was made to respect that setup.

I am guessing this was due to bug 1359905. If there were other reasons, I'm not sure how we can find out. But tests currently do seem to pass on all platforms.

Sorry, I had no idea you had asked a question in phabricator, as it was hiding it.

Comment 13

[Gian-Carlo Pascutto [:gcp]]

I am guessing this was due to bug 1359905.

I mean, that was not the bug of course, but it points to this commit, which unfortunately didn't have a bug attached:
https://hg.mozilla.org/mozilla-central/rev/663a3afb238e

The disabling was intentional, but seems no longer needed.

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/cfa5566d93a8
Fix missing linker and JS engine options for SSP. r=glandium
https://hg.mozilla.org/integration/autoland/rev/7e14986df45a
Split up macOS JIT tests in more chunks. r=jmaher

Comment 15

[Gian-Carlo Pascutto [:gcp]]

Talos didn't show any regressions. A small performance impact (as in the original patch) would not be unexpected, but I guess in the JS engine it's the JITed code that ends up running and that is not affected of course.

Comment 16

[Andrei Ciure[:aciure]]

https://hg.mozilla.org/mozilla-central/rev/cfa5566d93a8
https://hg.mozilla.org/mozilla-central/rev/7e14986df45a