Segfault when using static __thread variables with gold linker in linux

Segfault when using static __thread variables with gold linker in linux

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 :

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;

	}

Thanks!

29 posts / 0 nouveau(x)
Dernière contribution
Reportez-vous à notre Notice d'optimisation pour plus d'informations sur les choix et l'optimisation des performances dans les produits logiciels Intel.

Update : shorter repro :

int main(int argc, const char **argv) {
static __thread int lastID = -1;
 lastID = 0;
 return 0;
}

Can you post GDB dump of faulting process?

Attached

Fichiers joints: 

Fichier attachéTaille
Télécharger goldcrash-core.tgz1.29 Mo

I will look at this.

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? 

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

Fichiers joints: 

Fichier attachéTaille
Télécharger goldcrash.tgz5.13 Ko

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.

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.

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

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

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$

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?

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

 

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

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

Citation :

Richard G. a écrit :

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.

Citation :

iliyapolak a écrit :

 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).

Thanks Casey.

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

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

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

This is still causing segfaults with icc 14.0.2 and the latest binutils 2.24. I've had no reply from Intel support giving an ETA for a fix, our firm is moving to clang & gcc for development builds until this is fixed.

$ icc14 -o goldcrash goldcrash.cpp -B /spare/local/environ-infra/binutils/2.24/bin/gold -O0                                                        
$ ./goldcrash
Segmentation fault
$ icc14 --version
icc (ICC) 14.0.2 20140120
Copyright (C) 1985-2014 Intel Corporation.  All rights reserved.

$ ll /spare/local/environ-infra/binutils/2.24/bin/gold
total 0
lrwxrwxrwx 1 rgeary infra 10 Feb  3 11:23 ld -> ../ld.gold
$ /spare/local/environ-infra/binutils/2.24/bin/gold/ld --version
GNU gold (GNU Binutils 2.24) 1.11
Copyright 2013 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

$ cat goldcrash.cpp 
int main(int argc, const char **argv)
{
  static __thread int lastID = -1;
  lastID = 0;
  return 0;
}

 

Hello Richard,

I'm sorry, I don't have an ETA yet on when this is planned to be fixed.  Thanks for the feedback, I will pass that along to the developers.

Patrick

Hello Richard,

The developers are actively looking at this issue, although I do not yet have an ETA.  There seems to be something in our direct object generation that the gold linker doesn't like.  The problem can be worked around with -use-asm.

Patrick

This issue is now targeted to be fixed in the next update to icc-14 (update #3), which should be available around the end of April (caveat: plans are always subject to change).

Patrick

Resolved with icc-14.0.3.174. 

Patrick

Thanks, fix confirmed in 14.0.3, but still present in icc 15 beta (15.0.0 20140318)

The fix wasn't checked into the v15 branch until 4/2/2014, so it's not in the initial beta release.  I just checked, and it's fixed in beta update #1 (Version 15.0.0.040 Beta Build 20140428)

 

Patrick

Confirmed fixed in beta 15.0.0.040, thanks!

Laisser un commentaire

Veuillez ouvrir une session pour ajouter un commentaire. Pas encore membre ? Rejoignez-nous dès aujourd’hui