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

RESOLVED FIXED in Firefox 67

Status

defect
RESOLVED FIXED
3 months ago
2 months ago

People

(Reporter: petr.sumbera, Assigned: gcp)

Tracking

(Depends on 1 bug)

Trunk
mozilla67
Dependency tree / graph

Firefox Tracking Flags

(firefox67 fixed)

Details

Attachments

(2 attachments)

(Reporter)

Description

3 months ago

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

3 months ago

I should have added that I use gcc.

Any idea please?

Flags: needinfo?(mh+mozilla)

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
Flags: needinfo?(mh+mozilla)
Component: Untriaged → General
Product: Firefox → Firefox Build System
(Reporter)

Comment 3

2 months 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")?

Flags: needinfo?(mh+mozilla)
Flags: needinfo?(tom)
Flags: needinfo?(mh+mozilla)
Flags: needinfo?(agaynor)

Redirecting to :gcp who looked at these recently.

Flags: needinfo?(agaynor) → needinfo?(gpascutto)
(Assignee)

Comment 5

2 months 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?

Flags: needinfo?(gpascutto)

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

2 months 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...

Updated

2 months ago
Flags: needinfo?(tom)
(Assignee)

Comment 12

2 months 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.

Flags: needinfo?(mh+mozilla)
(Assignee)

Comment 13

2 months 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.

(Assignee)

Updated

2 months ago
Blocks: 1503589
Flags: needinfo?(mh+mozilla)

Comment 14

2 months 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

2 months 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

2 months ago
bugherder
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67
Assignee: nobody → gpascutto
You need to log in before you can comment on or make changes to this bug.