Undefined symbol __stack_chk_fail first referenced in file ../../../mozglue/build/SSE.o
Categories
(Firefox Build System :: General, defect)
Tracking
(firefox67 fixed)
Tracking | Status | |
---|---|---|
firefox67 | --- | fixed |
People
(Reporter: petr.sumbera, Assigned: gcp)
References
Details
Attachments
(2 files)
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.
Reporter | ||
Comment 1•5 years ago
|
||
I should have added that I use gcc.
Any idea please?
Comment 2•5 years ago
|
||
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
Updated•5 years ago
|
Reporter | ||
Comment 3•5 years ago
|
||
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")?
Updated•5 years ago
|
Comment 4•5 years ago
|
||
Redirecting to :gcp who looked at these recently.
Assignee | ||
Comment 5•5 years ago
|
||
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?
Assignee | ||
Comment 6•5 years ago
|
||
Assignee | ||
Comment 7•5 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=443cbcb6609930e646682c7123442eccc3611b1d
Comment 8•5 years ago
|
||
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.
Assignee | ||
Comment 9•5 years ago
|
||
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...
Assignee | ||
Comment 10•5 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=13c7660bd17a3504d0be0ae9617d5148ee34a411
Assignee | ||
Comment 11•5 years ago
|
||
Depends on D22730
Updated•5 years ago
|
Assignee | ||
Comment 12•5 years ago
•
|
||
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.
Assignee | ||
Comment 13•5 years ago
|
||
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.
Updated•5 years ago
|
Comment 14•5 years ago
|
||
Pushed by gpascutto@mozilla.com: 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
Assignee | ||
Comment 15•5 years ago
|
||
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•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/cfa5566d93a8
https://hg.mozilla.org/mozilla-central/rev/7e14986df45a
Updated•5 years ago
|
Updated•4 years ago
|
Description
•