Segfault when using static __thread variables with gold linker in linux

[Richard_G_4]

Hi,

I get a Segmentation Fault when using the intel compiler with the Gold linker in binutils. I don't get a segfault when using g++ 4.7.2. I've tested icc 12.1.3, 13.1.1 and 14.0.0 20130728. I'm using RHEL5.

Build command line :

icc14 goldcrash.cpp -o goldcrash -B <path to gold ld> && ./goldcrash

 (replace <path to gold ld> with the installation of binutils 2.23.2

goldcrash.cpp :

[cpp]

struct Simple {

Simple():m_id(0) {}
int m_id;
int getID() { return m_id; }
};

int main(int argc, const char **argv)
{
Simple s;
static __thread int lastID = -1;
if (lastID != s.getID())
{
  lastID = s.getID();
}
return 0;
}

[/cpp]

Thanks!

[Richard_G_4]

Update : shorter repro :

[cpp]

int main(int argc, const char **argv) {

static __thread int lastID = -1;
lastID = 0;
return 0;
}

[/cpp]

[Bernard]

Can you post GDB dump of faulting process?

[Richard_G_4]

Attached

[Bernard]

I will look at this.

[Bernard]

Hi Richard

I have unsuccessfuly tried to open the dump file.Can you instead of sending that file post the call stack of the faulting thread? 

[Richard_G_4]

Source, binary (with symbols) and obj file attached, plus goldcrash_ok for a non-gold linked binary produced from goldcrash.o.

I did notice some symbols from "nm goldcrash" are different when you link this with gold. Specifically, __dso_handle is an extern'd symbol (R) in goldcrash_ok and not (r) in goldcrash. __fini_array_start is "a" in goldcrash, and "a" in goldcrash_ok

Stack trace is uninteresting :

Program received signal SIGSEGV, Segmentation fault.

0x00000000004005b8 in main (argc=1, argv=0x7fffffffd998) at goldcrash.cpp:4
4 lastID = 0;
(gdb) backtrace
#0 0x00000000004005b8 in main (argc=1, argv=0x7fffffffd998) at goldcrash.cpp:4

[Bernard]

Hi Richard

I am using Windows and I am still unable to open those goldcrash files.Can you post the content of those files here in your thread.

[Richard_G_4]

Hi iliyapolak,

The gold linker is an ELF-only linker, the issue is only visible with linux. You can't use windows to reproduce this.

[pbkenned1]

Hi Richard,

I own your IPS case #6000030677.  I don't think this is an icc issue, nor an issue with the gold linker in binutils 2.23.2, so something else is going on with your system.  Unfortunately I cannot reproduce your SEGV with icc-14.0 and gold from binutils 2.23.2:

pbkenned@spdlvme060:~/quad/IPS/6000030677$ icc -V
Intel(R) C Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 14.0.0.080 Build 20130728
Copyright (C) 1985-2013 Intel Corporation.  All rights reserved.

pbkenned@spdlvme060:~/quad/IPS/6000030677$ icc -c goldcrash.cpp
pbkenned@spdlvme060:~/quad/IPS/6000030677$ gold --version
GNU gold (GNU Binutils for Ubuntu 2.23.2) 1.11

pbkenned@spdlvme060:~/quad/IPS/6000030677$ icc goldcrash.o -B/usr/bin/gold
pbkenned@spdlvme060:~/quad/IPS/6000030677$ ./a.out
pbkenned@spdlvme060:~/quad/IPS/6000030677$

The only difference I can spot between your system and mine is that I have a slightly later version of g++, v4.7.3, and you indicated 4.7.2. 

FWIW, g++ 4.7.3 works fine as well for your test case:

pbkenned@spdlvme060:~/quad/IPS/6000030677$ g++ --version
g++ (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3

pbkenned@spdlvme060:~/quad/IPS/6000030677$ g++ -c goldcrash.cpp && g++ goldcrash.o -B/usr/bin/gold && ./a.out
pbkenned@spdlvme060:~/quad/IPS/6000030677$

In any event, this doesn't really look like an issue with icc, nor an issue with gold 1.11

Thank you,

Patrick Kennedy

[Richard_G_4]

Can you try again with -O0 ?  I can repro your issue if I omit it, perhaps the compiler is optimizing away the local variable.

[pbkenned1]

no issue at -O0 either; I tested with 14.0.0.080 and 14.0.1.106 (the latest):

pbkenned@spdlvme060:~/quad/IPS/6000030677$ icc -V
Intel(R) C Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 14.0.1.106 Build 20131008
Copyright (C) 1985-2013 Intel Corporation.  All rights reserved.

pbkenned@spdlvme060:~/quad/IPS/6000030677$ rm -f *.o ./a.out
pbkenned@spdlvme060:~/quad/IPS/6000030677$ icc -c goldcrash.cpp -O0
pbkenned@spdlvme060:~/quad/IPS/6000030677$ icc goldcrash.o -B/usr/bin/gold -O0
pbkenned@spdlvme060:~/quad/IPS/6000030677$ ./a.out
pbkenned@spdlvme060:~/quad/IPS/6000030677$

[Richard_G_4]

I installed binutils 2.23.2 from source to a prefix dir (we don't have root access), so perhaps we have a difference there. I ran configure with --enable-gold --enable-plugins. 

What's in your /usr/bin/gold directory? It should be a symlink called ld to the gold linker binary. What do you get for "/usr/bin/gold/ld --version" ? If you run the binary I provided in the tarball, do you see the segfault?

[pbkenned1]

Hello Richard,

My Ubuntu test system came preconfigured with binutils 2.23.2.  Did someone with root access do a 'make install' of your build? Sometimes I cannot get a build of something running correctly without that final step.

Regarding my /usr/bin/gold:

pbkenned@spdlvme060:~$ ls -l /usr/bin/gold
lrwxrwxrwx 1 root root 7 Apr 16  2013 /usr/bin/gold -> ld.gold
pbkenned@spdlvme060:~$ /usr/bin/ld.gold --version
GNU gold (GNU Binutils for Ubuntu 2.23.2) 1.11

Regarding your binary, yes, it does SEGV on my system.  I couldn't determine what the issue was by running in the debugger.  And running 'nm' on your binary produces quite a lot of differences compared to the binary I generated from your source example on my system.  I can't explain the differences.  I can say however that the nm output of a gcc build and icc build are pretty similar, for example, __dso_handle is defined in both:

pbkenned@spdlvme060:~/quad/IPS/6000030677$ nm goldcrash-14.0.1.106.x |grep dso
00000000006036a8 D __dso_handle
pbkenned@spdlvme060:~/quad/IPS/6000030677$ nm goldcrash-gcc-4.7.3.x |grep dso
0000000000601030 D __dso_handle
pbkenned@spdlvme060:~/quad/IPS/6000030677$

Regards,

Patrick

[Richard_G_4]

Hi Patrick,

I believe the -B flag expects a directory argument, and it looks for a file named ld in that directory. So in your case, your -B flag probably wasn't using the gold ld linker. Try creating a new directory containing a symlink named "ld" pointing to /usr/bin/ld.gold and use that dir with -B. You can verify which linker it's using by running the link step through strace -f and watching which files it opens.

Thanks,

Richard

[pbkenned1]

Hi Richard,

Thanks for the suggestions.  I created subdirectory 'mygold' and did a symbolic link to /usr/bin/ld.gold.  I think it's clear the gold linker was used.  Still can't repo:

pbkenned@spdlvme060:~/quad/IPS/6000030677$ ls -l ./mygold/
total 0
lrwxrwxrwx 1 pbkenned cmplr 16 Oct 31  2013 ld -> /usr/bin/ld.gold
pbkenned@spdlvme060:~/quad/IPS/6000030677$ strace icc goldcrash.cpp -Qlocation,link,./mygold > strace_ld.gold_link.txt 2>&1
pbkenned@spdlvme060:~/quad/IPS/6000030677$ ./a.out
pbkenned@spdlvme060:~/quad/IPS/6000030677$ grep gold strace_ld.gold_link.txt
execve("/tools/composer_xe_2013_sp1.1.106/bin/intel64/icc", ["icc", "goldcrash.cpp", "-Qlocation,link,./mygold"], [/* 215 vars */]) = 0
open("goldcrash.cpp", O_RDONLY)         = 3
read(3, "GNU gold (GNU Binutils for Ubunt"..., 4096) = 286
read(3, "GNU gold (GNU Binutils for Ubunt"..., 4096) = 286
read(3, "GNU gold (GNU Binutils for Ubunt"..., 4096) = 286
pbkenned@spdlvme060:~/quad/IPS/6000030677$

Thanks,

Patrick

[Bernard]

Richard G. wrote:

Hi iliyapolak,

The gold linker is an ELF-only linker, the issue is only visible with linux. You can't use windows to reproduce this.

 I thought that the file uploaded by you is some kind of dump file.

[Casey]

iliyapolak wrote:

 I thought that the file uploaded by you is some kind of dump file.

The file he posted is a dump, but you'll need a debugger that can open GDB style core dumps, and to be of any use, you'll also need a debugger that can load symbols from ELF executables, which pretty much limits your options to GDB and the Intel debugger on Linux or OSX.  The MSVC debugger on windows won't have a clue what to do with these files (windows executables are PE format and it knows nothing of ELF).

[Bernard]

Thanks Casey.

I will use guest OS(Backtrack) GDB  to open that dump file.

[Richard_G_4]

Hi Patrick,

I can reproduce this on Ubuntu 12.04 LTS with /usr/bin/ld.gold when I use -O0. In your last post I didn't see a -O0 option in your command.

[richard@ubuntu:goldcrash]$ icpc goldcrash.cpp -Qlocation,link,./mygold -o goldcrash -O0
[richard@ubuntu:goldcrash]$ ./goldcrash
Segmentation fault (core dumped)
[richard@ubuntu:goldcrash]$ ll ./mygold/
total 0
lrwxrwxrwx 1 richard richard 16 Nov 4 23:34 ld -> /usr/bin/ld.gold

[richard@ubuntu:goldcrash]$ uname -a
Linux ubuntu 3.2.0-55-generic #85-Ubuntu SMP Wed Oct 2 12:29:27 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

[pbkenned1]

Hello Richard,

Sorry for the delayed response.  Indeed, the problem is only apparent at -O0.  It took me extra time to uncover what optimisation was masking the problem at -O1 or higher -- it's dead code elimination.  I reported this to the developers as issue # DPD200249847.  I'll keep this thread updated with news.

Thanks for being persistent!

Patrick