Strange ld.gold segmentation error issues.

ISHIKAWA,chiaki ishikawa@yk.rim.or.jp
Wed Jun 4 14:59:00 GMT 2014


(Sorry for top-posting, but the quoted e-mail gets longer and
I want to state the essential stuff at the beginning.)

Hi,

Thank you again for your help.

I found the file being read using print *object in frame #8.
It is a file called io/./prmapopt.o.

(I put the full output of print *object from the
automatic invocation of gdb during build at the end of the message.)

The linker was invoked with the following directory as the current
directory.

REF-OBJ-DIR/objdir-tb3/mozilla/nsprpub/pr/src

ishikawa@vm-debian-amd64:/REF-OBJ-DIR/objdir-tb3/mozilla/nsprpub/pr/src$ 
LANG=C
ishikawa@vm-debian-amd64:/REF-OBJ-DIR/objdir-tb3/mozilla/nsprpub/pr/src$ 
ls -l
total 1324
drwxr-xr-x 10 ishikawa ishikawa    4096 Jun  4 23:14 ./
drwxr-xr-x  5 ishikawa ishikawa    4096 Jun  4 23:14 ../
-rw-r--r--  1 ishikawa ishikawa    9235 Jun  4 23:14 Makefile
-rw-r--r--  1 ishikawa ishikawa     106 Jun  4 23:14 _pr_bld.h
drwxr-xr-x  2 ishikawa ishikawa    4096 Jun  4 23:14 io/
-rw-r--r--  1 ishikawa ishikawa 1280004 Jun  4 23:14 libnspr4.a
drwxr-xr-x  2 ishikawa ishikawa    4096 Jun  4 23:14 linking/
drwxr-xr-x  2 ishikawa ishikawa    4096 Jun  4 23:14 malloc/
drwxr-xr-x  3 ishikawa ishikawa    4096 Jun  4 23:14 md/
drwxr-xr-x  2 ishikawa ishikawa    4096 Jun  4 23:14 memory/
drwxr-xr-x  2 ishikawa ishikawa    4096 Jun  4 23:14 misc/
-rw-r--r--  1 ishikawa ishikawa    3297 Jun  4 23:14 prvrsion.dwo
-rw-r--r--  1 ishikawa ishikawa    4600 Jun  4 23:14 prvrsion.o
drwxr-xr-x  2 ishikawa ishikawa    4096 Jun  4 23:14 pthreads/
drwxr-xr-x  2 ishikawa ishikawa    4096 Jun  4 23:14 threads/
ishikawa@vm-debian-amd64:/REF-OBJ-DIR/objdir-tb3/mozilla/nsprpub/pr/src$ 
tar czvf /tmp/t.tar.gz libnspr4.a io/prmapopt.o io/prmapopt.dwo
libnspr4.a
io/prmapopt.o
io/prmapopt.dwo
ishikawa@vm-debian-amd64:/REF-OBJ-DIR/objdir-tb3/mozilla/nsprpub/pr/src$ 
ls -l /tmp/t.tar.gz
-rw-r--r-- 1 ishikawa root 343261 Jun  4 23:19 /tmp/t.tar.gz
ishikawa@vm-debian-amd64:/REF-OBJ-DIR/objdir-tb3/mozilla/nsprpub/pr/src$

I will send /tmp/t.tar.gz personally (not the whole list).
If someone else needs it for debugging, please let me know.

Since I use -gsplit-dwarf to gcc and --gdb-index to GNU gold, and that 
seems to be relevant here, I included io/./prmapopt.dwo as well.

Thank you in advance.

Chiaki


Side note: Mystery 1.

What has puzzled me is that I tried to invoke the GNU gold with
the same argument list that have caused the crash here, but I could
not reproduce the crash manually. Not even that, then it seemed
to create libnspr4.so (!?)

I checked various environment variable setting that *I* set manually 
before calling make in my script, but they did not seem have any effect 
on ld behavior.

But I wonder if GCC in its wisdom sets up very special environment
variables in executing ld (?) to change its behavior in a subtle
manner (in addition to passing options explicitly on the command
line)?
Hard to believe, but I can't think of other explanation. (Short of
GNU gold breaking or rewriting some files as the side effect of crash,
but it is very unlikely.)

Maybe because of this, somehow that if I invoke the top-level make in
TB's source directory after the crash due to segmentation error, that
invocation seems to create libnspr4.so without experiencing the crash
(???) and build goes on merrily. Something is fishy with the way GNU 
gold behaves under my environment.

Here is the exact scenario of manual invocation of GNU gold which
somehow seemed to work (?!)

Let me try to run gdb in the above directory immediately after the
crash. You may be surprised to see that ld.new run under gdb runs to
completion, and libnspr4.so is created !?
Is there any other files that are touched by the invocation of GNU
gold (in my case /usr/bin/ld.new)?

Maybe I am missing the obvious, but I need a third-party observation
to find out.

Strange Behavior.

Note that there is no libnspr4.so before the start:
I start gdb and load /usr/bin/ld.new (GNU gold) under my environment.
Run with the same argument as far as I can tell.

ishikawa@vm-debian-amd64:/REF-OBJ-DIR/objdir-tb3/mozilla/nsprpub/pr/src$ 
ls -l
total 1324
drwxr-xr-x 10 ishikawa ishikawa    4096 Jun  4 23:14 ./
drwxr-xr-x  5 ishikawa ishikawa    4096 Jun  4 23:14 ../
-rw-r--r--  1 ishikawa ishikawa    9235 Jun  4 23:14 Makefile
-rw-r--r--  1 ishikawa ishikawa     106 Jun  4 23:14 _pr_bld.h
drwxr-xr-x  2 ishikawa ishikawa    4096 Jun  4 23:14 io/
-rw-r--r--  1 ishikawa ishikawa 1280004 Jun  4 23:14 libnspr4.a
drwxr-xr-x  2 ishikawa ishikawa    4096 Jun  4 23:14 linking/
drwxr-xr-x  2 ishikawa ishikawa    4096 Jun  4 23:14 malloc/
drwxr-xr-x  3 ishikawa ishikawa    4096 Jun  4 23:14 md/
drwxr-xr-x  2 ishikawa ishikawa    4096 Jun  4 23:14 memory/
drwxr-xr-x  2 ishikawa ishikawa    4096 Jun  4 23:14 misc/
-rw-r--r--  1 ishikawa ishikawa    3297 Jun  4 23:14 prvrsion.dwo
-rw-r--r--  1 ishikawa ishikawa    4600 Jun  4 23:14 prvrsion.o
drwxr-xr-x  2 ishikawa ishikawa    4096 Jun  4 23:14 pthreads/
drwxr-xr-x  2 ishikawa ishikawa    4096 Jun  4 23:14 threads/
ishikawa@vm-debian-amd64:/REF-OBJ-DIR/objdir-tb3/mozilla/nsprpub/pr/src$ gdb
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Warning: /REF-OBJ-DIR/objdir-tb3/mozilla/build/unix/elfhack: No such 
file or directory.
Warning: /REF-OBJ-DIR/objdir-tb3/mozilla/dom/file: No such file or 
directory.
Warning: /REF-OBJ-DIR/objdir-tb3/mozilla/security/sandbox/linux: No such 
file or directory.
Warning: /REF-OBJ-DIR/objdir-tb3/mozilla/toolkit/components/intl: No 
such file or directory.
(gdb) file /usr/bin/ld.new
Reading symbols from /usr/bin/ld.new...done.
(gdb) run --sysroot=/ --build-id --eh-frame-hdr -m elf_x86_64 
--hash-style=gnu -shared -o libnspr4.so 
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crti.o 
/usr/lib/gcc/x86_64-linux-gnu/4.8/crtbeginS.o 
-L/usr/lib/gcc/x86_64-linux-gnu/4.8 
-L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu 
-L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib 
-L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu 
-L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../.. 
--gdb-index -soname libnspr4.so ./prvrsion.o io/./prfdcach.o 
io/./prmwait.o io/./prmapopt.o io/./priometh.o io/./pripv6.o 
io/./prlayer.o io/./prlog.o io/./prmmap.o io/./prpolevt.o io/./prprf.o 
io/./prscanf.o io/./prstdio.o threads/./prcmon.o threads/./prrwlock.o 
threads/./prtpd.o linking/./prlink.o malloc/./prmalloc.o 
malloc/./prmem.o md/./prosdep.o memory/./prshm.o memory/./prshma.o 
memory/./prseg.o misc/./pralarm.o misc/./pratom.o misc/./prcountr.o 
misc/./prdtoa.o misc/./prenv.o misc/./prerr.o misc/./prerror.o 
misc/./prerrortable.o misc/./prinit.o misc/./prinrval.o misc/./pripc.o 
misc/./prlog2.o misc/./prlong.o misc/./prnetdb.o misc/./praton.o 
misc/./prolock.o misc/./prrng.o misc/./prsystem.o misc/./prthinfo.o 
misc/./prtpool.o misc/./prtrace.o misc/./prtime.o pthreads/./ptsynch.o 
pthreads/./ptio.o pthreads/./ptthread.o pthreads/./ptmisc.o 
md/unix/./unix.o md/unix/./unix_errors.o md/unix/./uxproces.o 
md/unix/./uxrng.o md/unix/./uxshm.o md/unix/./uxwrap.o md/unix/./linux.o 
md/unix/./os_Linux_x86_64.o -z text --build-id -lpthread -ldl -lrt -lgcc 
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s 
--no-as-needed /usr/lib/gcc/x86_64-linux-gnu/4.8/crtendS.o 
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crtn.o

Starting program: /usr/bin/ld.new --sysroot=/ --build-id --eh-frame-hdr 
-m elf_x86_64 --hash-style=gnu -shared -o libnspr4.so 
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crti.o 
/usr/lib/gcc/x86_64-linux-gnu/4.8/crtbeginS.o 
-L/usr/lib/gcc/x86_64-linux-gnu/4.8 
-L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu 
-L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib 
-L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu 
-L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../.. 
--gdb-index -soname libnspr4.so ./prvrsion.o io/./prfdcach.o 
io/./prmwait.o io/./prmapopt.o io/./priometh.o io/./pripv6.o 
io/./prlayer.o io/./prlog.o io/./prmmap.o io/./prpolevt.o io/./prprf.o 
io/./prscanf.o io/./prstdio.o threads/./prcmon.o threads/./prrwlock.o 
threads/./prtpd.o linking/./prlink.o malloc/./prmalloc.o 
malloc/./prmem.o md/./prosdep.o memory/./prshm.o memory/./prshma.o 
memory/./prseg.o misc/./pralarm.o misc/./pratom.o misc/./prcountr.o 
misc/./prdtoa.o misc/./prenv.o misc/./prerr.o misc/./prerror.o 
misc/./prerrortable.o misc/./prinit.o misc/./prinrval.o misc/./pripc.o 
misc/./prlog2.o misc/./prlong.o misc/./prnetdb.o misc/./praton.o 
misc/./prolock.o misc/./prrng.o misc/./prsystem.o misc/./prthinfo.o 
misc/./prtpool.o misc/./prtrace.o misc/./prtime.o pthreads/./ptsynch.o 
pthreads/./ptio.o pthreads/./ptthread.o pthreads/./ptmisc.o 
md/unix/./unix.o md/unix/./unix_errors.o md/unix/./uxproces.o 
md/unix/./uxrng.o md/unix/./uxshm.o md/unix/./uxwrap.o md/unix/./linux.o 
md/unix/./os_Linux_x86_64.o -z text --build-id -lpthread -ldl -lrt -lgcc 
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s 
--no-as-needed /usr/lib/gcc/x86_64-linux-gnu/4.8/crtendS.o 
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crtn.o
warning: the debug information found in "/lib64/ld-2.18.so" does not 
match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch).

warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Inferior 1 (process 30918) exited normally]
(gdb) (gdb)
(gdb) quit
ishikawa@vm-debian-amd64:/REF-OBJ-DIR/objdir-tb3/mozilla/nsprpub/pr/src$ 
ls -l
total 3188
drwxr-xr-x 10 ishikawa ishikawa    4096 Jun  4 23:31 ./
drwxr-xr-x  5 ishikawa ishikawa    4096 Jun  4 23:14 ../
-rw-r--r--  1 ishikawa ishikawa    9235 Jun  4 23:14 Makefile
-rw-r--r--  1 ishikawa ishikawa     106 Jun  4 23:14 _pr_bld.h
drwxr-xr-x  2 ishikawa ishikawa    4096 Jun  4 23:14 io/
-rw-r--r--  1 ishikawa ishikawa 1280004 Jun  4 23:14 libnspr4.a
-rwxr-xr-x  1 ishikawa ishikawa 1902774 Jun  4 23:31 libnspr4.so*
drwxr-xr-x  2 ishikawa ishikawa    4096 Jun  4 23:14 linking/
drwxr-xr-x  2 ishikawa ishikawa    4096 Jun  4 23:14 malloc/
drwxr-xr-x  3 ishikawa ishikawa    4096 Jun  4 23:14 md/
drwxr-xr-x  2 ishikawa ishikawa    4096 Jun  4 23:14 memory/
drwxr-xr-x  2 ishikawa ishikawa    4096 Jun  4 23:14 misc/
-rw-r--r--  1 ishikawa ishikawa    3297 Jun  4 23:14 prvrsion.dwo
-rw-r--r--  1 ishikawa ishikawa    4600 Jun  4 23:14 prvrsion.o
drwxr-xr-x  2 ishikawa ishikawa    4096 Jun  4 23:14 pthreads/
drwxr-xr-x  2 ishikawa ishikawa    4096 Jun  4 23:14 threads/
ishikawa@vm-debian-amd64:/REF-OBJ-DIR/objdir-tb3/mozilla/nsprpub/pr/src$

Note that now libnspr4.so (!!!)



cf. This is the full print *object:

(gdb) $4 = (gold::Sized_relobj_file<64, false>) {<gold::Sized_relobj<64, 
false>> = {<gold::Relobj> = {<gold::Object> = {
         _vptr.Object = 0x6c1d30 <vtable for gold::Sized_relobj_file<64, 
false>+16>, name_ = {static npos = <optimized out>,
           _M_dataplus = {<std::allocator<char>> = 
{<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>},
             _M_p = 0x773608 "io/./prmapopt.o"}}, input_file_ = 0x94a7a0,
         offset_ = 0, shnum_ = 26, is_dynamic_ = false, is_needed_ = false,
         uses_split_stack_ = false, has_no_split_stack_ = false,
         no_export_ = false, is_in_system_directory_ = false,
         as_needed_ = false, xindex_ = 0x0},
       output_sections_ = {<std::_Vector_base<gold::Output_section*, 
std::allocator<gold::Output_section*> >> = {
           _M_impl = {<std::allocator<gold::Output_section*>> = 
{<__gnu_cxx::new_allocator<gold::Output_section*>> = {<No data fields>}, 
<No data fields>},
             _M_start = 0x9474c0, _M_finish = 0x947590,
             _M_end_of_storage = 0x947590}}, <No data fields>},
       map_to_relocatable_relocs_ = 0x0, object_merge_map_ = 0x9478c0,
       relocs_must_follow_section_writes_ = true, rd_ = 0x950890, sd_ = 
0x0,
       reloc_counts_ = 0x0, reloc_bases_ = 0x0, first_dyn_reloc_ = 0,
       dyn_reloc_count_ = 0}, static invalid_address = <optimized out>,
     local_got_offsets_ = {<std::tr1::__unordered_map<unsigned int, 
gold::Got_offset_list*, std::tr1::hash<unsigned int>, 
std::equal_to<unsigned int>, std::allocator<std::pair<unsigned int 
const, gold::Got_offset_list*> >, false>> = 
{<std::tr1::_Hashtable<unsigned int, std::pair<unsigned int const, 
gold::Got_offset_list*>, std::allocator<std::pair<unsigned int const, 
gold::Got_offset_list*> >, std::_Select1st<std::pair<unsigned int const, 
gold::Got_offset_list*> >, std::equal_to<unsigned int>, 
std::tr1::hash<unsigned int>, std::tr1::__detail::_Mod_range_hashing, 
std::tr1::__detail::_Default_ranged_hash, 
std::tr1::__detail::_Prime_rehash_policy, false, false, true>> = 
{<std::tr1::__detail::_Rehash_base<std::tr1::__detail::_Prime_rehash_policy, 
std::tr1::_Hashtable<unsigned int, std::pair<unsigned int const, 
gold::Got_offset_list*>, std::allocator<std::pair<unsigned int const, 
gold::Got_offset_list*> >, std::_Select1st<std::pair<unsigned int const, 
gold::Got_offset_list*> >, std::equal_to<unsigned int>, 
std::tr1::hash<unsigned int>, std::tr1::__detail::_Mod_range_hashing, 
std::tr1::__detail::_Default_ranged_hash, 
std::tr1::__detail::_Prime_rehash_policy, false, false, true> >> = {<No 
data fields>}, <std::tr1::__detail::_Hash_code_base<unsigned int, 
std::pair<unsigned int const, gold::Got_offset_list*>, 
std::_Select1st<std::pair<unsigned int const, gold::Got_offset_list*> >, 
std::equal_to<unsigned int>, std::tr1::hash<unsigned int>, 
std::tr1::__detail::_Mod_range_hashing, 
std::tr1::__detail::_Default_ranged_hash, false>> = {
             _M_extract = {<std::unary_function<std::pair<unsigned int 
const, gold::Got_offset_list*>, unsigned int const>> = {<No data 
fields>}, <No data fields>},
             _M_eq = {<std::binary_function<unsigned int, unsigned int, 
bool>> = {<No data fields>}, <No data fields>},
             _M_h1 = {<std::unary_function<unsigned int, unsigned long>> 
= {<No data fields>}, <No data fields>},
             _M_h2 = {<No data fields>}}, 
<std::tr1::__detail::_Map_base<unsigned int, std::pair<unsigned int 
const, gold::Got_offset_list*>, std::_Select1st<std::pair<unsigned int 
const, gold::Got_offset_list*> >, true, std::tr1::_Hashtable<unsigned 
int, std::pair<unsigned int const, gold::Got_offset_list*>, 
std::allocator<std::pair<unsigned int const, gold::Got_offset_list*> >, 
std::_Select1st<std::pair<unsigned int const, gold::Got_offset_list*> >, 
std::equal_to<unsigned int>, std::tr1::hash<unsigned int>, 
std::tr1::__detail::_Mod_range_hashing, 
std::tr1::__detail::_Default_ranged_hash, 
std::tr1::__detail::_Prime_rehash_policy, false, false, true> >> = {<No 
data fields>},
           _M_node_allocator = 
{<__gnu_cxx::new_allocator<std::tr1::__detail::_Hash_node<std::pair<unsigned 
int const, gold::Got_offset_list*>, false> >> = {<No data fields>}, <No 
data fields>}, _M_buckets = 0x919810,
           _M_bucket_count = 11, _M_element_count = 0, _M_rehash_policy = {
             _M_max_load_factor = 1, _M_growth_factor = 2,
             _M_next_resize = 11}}, <No data fields>}, <No data fields>},
     section_offsets_ = {<std::_Vector_base<unsigned long, 
std::allocator<unsigned long> >> = {
         _M_impl = {<std::allocator<unsigned long>> = 
{<__gnu_cxx::new_allocator<unsigned long>> = {<No data fields>}, <No 
data fields>},
           _M_start = 0x9475a0, _M_finish = 0x947670,
           _M_end_of_storage = 0x947670}}, <No data fields>}},
   static invalid_address = <optimized out>,
   static ehdr_size = <optimized out>, static shdr_size = <optimized out>,
   static sym_size = <optimized out>, elf_file_ = {
     static ehdr_size = <optimized out>, static phdr_size = <optimized 
out>,
     static shdr_size = <optimized out>, static sym_size = <optimized out>,
     static rel_size = <optimized out>, static rela_size = <optimized out>,
     file_ = 0x946f90, shoff_ = 2768, shnum_ = 26, shstrndx_ = 23,
     large_shndx_offset_ = 0}, e_type_ = 1, symtab_shndx_ = 24,
   local_symbol_count_ = 18, output_local_symbol_count_ = 0,
   output_local_dynsym_count_ = 0,
   symbols_ = {<std::_Vector_base<gold::Symbol*, 
std::allocator<gold::Symbol*> >> = {
       _M_impl = {<std::allocator<gold::Symbol*>> = 
{<__gnu_cxx::new_allocator<gold::Symbol*>> = {<No data fields>}, <No 
data fields>}, _M_start = 0x0,
         _M_finish = 0x0, _M_end_of_storage = 0x0}}, <No data fields>},
   defined_count_ = 0, local_symbol_offset_ = 0, local_dynsym_offset_ = 0,
   local_values_ = {<std::_Vector_base<gold::Symbol_value<64>, 
std::allocator<gold::Symbol_value<64> > >> = {
       _M_impl = {<std::allocator<gold::Symbol_value<64> >> = 
{<__gnu_cxx::new_allocator<gold::Symbol_value<64> >> = {<No data 
fields>}, <No data fields>},
         _M_start = 0x947220, _M_finish = 0x9473d0,
         _M_end_of_storage = 0x9473d0}}, <No data fields>},
   local_plt_offsets_ = {<std::tr1::__unordered_map<unsigned int, 
unsigned int, std::tr1::hash<unsigned int>, std::equal_to<unsigned int>, 
std::allocator<std::pair<unsigned int const, unsigned int> >, false>> = 
{<std::tr1::_Hashtable<unsigned int, std::pair<unsigned int const, 
unsigned int>, std::allocator<std::pair<unsigned int const, unsigned 
int> >, std::_Select1st<std::pair<unsigned int const, unsigned int> >, 
std::equal_to<unsigned int>, std::tr1::hash<unsigned int>, 
std::tr1::__detail::_Mod_range_hashing, 
std::tr1::__detail::_Default_ranged_hash, 
std::tr1::__detail::_Prime_rehash_policy, false, false, true>> = 
{<std::tr1::__detail::_Rehash_base<std::tr1::__detail::_Prime_rehash_policy, 
std::tr1::_Hashtable<unsigned int, std::pair<unsigned int const, 
unsigned int>, std::allocator<std::pair<unsigned int const, unsigned 
int> >, std::_Select1st<std::pair<unsigned int const, unsigned int> >, 
std::equal_to<unsigned int>, std::tr1::hash<unsigned int>, 
std::tr1::__detail::_Mod_range_hashing, 
std::tr1::__detail::_Default_ranged_hash, 
std::tr1::__detail::_Prime_rehash_policy, false, false, true> >> = {<No 
data fields>}, <std::tr1::__detail::_Hash_code_base<unsigned int, 
std::pair<unsigned int const, unsigned int>, 
std::_Select1st<std::pair<unsigned int const, unsigned int> >, 
std::equal_to<unsigned int>, std::tr1::hash<unsigned int>, 
std::tr1::__detail::_Mod_range_hashing, 
std::tr1::__detail::_Default_ranged_hash, false>> = {
           _M_extract = {<std::unary_function<std::pair<unsigned int 
const, unsigned int>, unsigned int const>> = {<No data fields>}, <No 
data fields>},
           _M_eq = {<std::binary_function<unsigned int, unsigned int, 
bool>> = {<No data fields>}, <No data fields>},
           _M_h1 = {<std::unary_function<unsigned int, unsigned long>> = 
{<No data fields>}, <No data fields>},
           _M_h2 = {<No data fields>}}, 
<std::tr1::__detail::_Map_base<unsigned int, std::pair<unsigned int 
const, unsigned int>, std::_Select1st<std::pair<unsigned int const, 
unsigned int> >, true, std::tr1::_Hashtable<unsigned int, 
std::pair<unsigned int const, unsigned int>, 
std::allocator<std::pair<unsigned int const, unsigned int> >, 
std::_Select1st<std::pair<unsigned int const, unsigned int> >, 
std::equal_to<unsigned int>, std::tr1::hash<unsigned int>, 
std::tr1::__detail::_Mod_range_hashing, 
std::tr1::__detail::_Default_ranged_hash, 
std::tr1::__detail::_Prime_rehash_policy, false, false, true> >> = {<No 
data fields>},
         _M_node_allocator = 
{<__gnu_cxx::new_allocator<std::tr1::__detail::_Hash_node<std::pair<unsigned 
int const, unsigned int>, false> >> = {<No data fields>}, <No data 
fields>}, _M_buckets = 0x8b55b0, _M_bucket_count = 11,
         _M_element_count = 0, _M_rehash_policy = {_M_max_load_factor = 1,
           _M_growth_factor = 2,
           _M_next_resize = 11}}, <No data fields>}, <No data fields>},
   kept_comdat_sections_ = {_M_t = {
       _M_impl = {<std::allocator<std::_Rb_tree_node<std::pair<unsigned 
int const, gold::Sized_relobj_file<64, false>::Kept_comdat_section> > >> 
= {<__gnu_cxx::new_allocator<std::_Rb_tree_node<std::pair<unsigned int 
const, gold::Sized_relobj_file<64, false>::Kept_comdat_section> > >> = 
{<No data fields>}, <No data fields>},
         _M_key_compare = {<std::binary_function<unsigned int, unsigned 
int, bool>> = {<No data fields>}, <No data fields>}, _M_header = {
           _M_color = std::_S_red, _M_parent = 0x0, _M_left = 0x947118,
           _M_right = 0x947118}, _M_node_count = 0}}}, has_eh_frame_ = 
true,
   discarded_eh_frame_shndx_ = 21,
   deferred_layout_ = {<std::_Vector_base<gold::Sized_relobj_file<64, 
false>::Deferred_layout, std::allocator<gold::Sized_relobj_file<64, 
false>::Deferred_layout> >> = {
       _M_impl = {<std::allocator<gold::Sized_relobj_file<64, 
false>::Deferred_layout>> = 
{<__gnu_cxx::new_allocator<gold::Sized_relobj_file<64, 
false>::Deferred_layout>> = {<No data fields>}, <No data fields>}, 
_M_start = 0x0,
         _M_finish = 0x0, _M_end_of_storage = 0x0}}, <No data fields>},
   deferred_layout_relocs_ = 
{<std::_Vector_base<gold::Sized_relobj_file<64, false>::Deferred_layout, 
std::allocator<gold::Sized_relobj_file<64, false>::Deferred_layout> >> = {
       _M_impl = {<std::allocator<gold::Sized_relobj_file<64, 
false>::Deferred_layout>> = 
{<__gnu_cxx::new_allocator<gold::Sized_relobj_file<64, 
false>::Deferred_layout>> = {<No data fields>}, <No data fields>}, 
_M_start = 0x0,
         _M_finish = 0x0, _M_end_of_storage = 0x0}}, <No data fields>},
   compressed_sections_ = 0x0}


(2014/06/04 23:44), ISHIKAWA,chiaki wrote:
> Hi,
>
> Thank you for the comment.
>
> (2014/06/03 3:30), Cary Coutant wrote:
>>> Oh, I am using -gsplit-dwarf switch to gcc, g++, and
>>> pass -gdb-index to gold. Does it matter? (with the older version of
>>> GNU gold, it did not cause this segmentation error.)
>>
>> The crash is in the code that creates the .gdb_index section, so that
>> option is definitely significant.
>
> I see. It gets interesting :-)
>
>>
>>> Initially, I suspected that it could be an OOM issue since there are
>>> many processes running "make -j4 ...", but then I found I have more
>>> than 2.5 GB of main memory is free at the time the GNU gold  binary was
>>> invoked to produce a .so library just before the segfault occurs The
>>> library is NOT THAT big.
>>>
>>> Also, to my surprise, changing "-j4" make switch to "-j3" did not
>>> change the issue. Even with less number of processes invoked by make,
>>> the segfault still occurred. So OOM is unlikely, and come to think of
>>> it, if OOM had happened, the kernel should have recorded it, but I did
>>> not see such messages in kernel logs.
>>>
>>> Anyway, so, I modified my local version of "ld" to invoke a shell
>>> script, which
>>> checks if the particular library (here libnspr4.so) is going to be
>>> created, and if so, invokes ld.new (gold binary) under gdb and see
>>> what happens. Otherwise it simply invokes gold binary with the passed
>>> arguments.
>>> (In the previous posting, I thought it was libmozalloc.so that caused
>>> the blowup, but as it turned out it is the next target, libnspr4.so)
>>>
>>>
>>> Funny, the first few times, it did not trip ?!??
>>> Maybe I was doing something wrong.
>>> On the third try, I could capture the stacktrace.
>>
>> This is puzzling. I'd think a problem like this would be reproducible,
>> unless there's some sort of race going on with the .o files. Does the
>> problem go away if you change make to use "-j1"?
>>
> Yes, indeed it was puzzling. I thought it was my manual operation error,
> but I will check this in parallel with my effort to trace down which
> object file is causing the trouble.
>
> It is possible that mozilla thunderbird has gone a major build system
> revision in the last 12 months, and there may be still some issues of
> building the binaries. But since the objects linked are for a library
> and it is under a file tree hierarchy, I am not sure how can object
> creation can be mixed up by "-j4" (IF makefile is written/created
> correctly, that is.)
>
>>> [I obtained three dumps.
>>> One with my stock ~/.gdbinit tailored to mozilla thunderbird
>>> debugging. But it contained a set of spurious warnings related to
>>> files referenced in .gdbinit.
>>> The 2nd ONE was obtained after this .gdbinit file renamed to
>>> .gdbinit.save
>>> to remove the spurious warning.
>>> The 3rd one was obtained after I cleared ccache completely.
>>> I cleared ccache's cache to make sure
>>> that I am not using corrupt object files (for some mysterious
>>> reason). I use a version of ccache enhanced to support -gsplit-dwarf.
>>> https://bitbucket.org/zephyrus00jp/ccache-gsplit-dwarf-support
>>> https://bugzilla.samba.org/show_bug.cgi?id=10005
>>>
>>> The second and third stack trace matched completely (except for the
>>> process ID that is printed at the end.) So I am sure ccache is not
>>> involved with the problem.
>>> So I am showing the 3rd dump below.
>>>
>>> Funny thing is that I can re-invoke top-most make -f client.mk with
>>> suitable environment variable setting, etc., and can create a working
>>> mozilla thunderbird (!?) I wonder in what condition the left over
>>> libnspr4.so is. Maybe the link/build system of mozilla thunderbird is
>>> clever enough to figure out that libnspr4.a is used instead(?), but I
>>> digress.
>>
>> Since the linker is crashing early during the first pass, it will not
>> have even created the output file yet, so you are probably left with
>> an older copy left over from a link that did not crash.
>>
>
> I see. That may explain it.
> I suppose .PRECIOUS or whatever is used in Makefile(s) not to remove
> library file before the command is executed.
>
>>> Program received signal SIGSEGV, Segmentation fault.
>>> gold::Gdb_index::add_symbol (this=0x901e90, cu_index=3,
>>>      sym_name=0x2aaaaaaec000 <Address 0x2aaaaaaec000 out of bounds>,
>>>      flags=0 '\000') at gdb-index.cc:1128
>>> 1128          reinterpret_cast<const unsigned char*>(sym_name));
>>> (gdb) #0  gold::Gdb_index::add_symbol (this=0x901e90, cu_index=3,
>>>      sym_name=0x2aaaaaaec000 <Address 0x2aaaaaaec000 out of bounds>,
>>>      flags=0 '\000') at gdb-index.cc:1128
>>> #1  0x0000000000517602 in gold::Gdb_index_info_reader::read_pubtable (
>>>      this=0x7fffffff5a30, table=0x9022d0, offset=<optimized out>)
>>>      at gdb-index.cc:879
>>
>> This is definitely helpful -- thanks for going through so much trouble
>> to get these stack traces. This shows that we are in the middle of
>> hashing a name from the .debug_pubnames (or .debug_gnu_pubnames)
>> table, but for some reason we have a name that runs off the end of the
>> table with no null-termination. That should not happen, and suggests a
>> corrupt .o file. It would be helpful to figure out which .o file we're
>> reading at this point, but I'll need you to do a bit more to collect
>> that...
>>
>
> OK
>
>>> #2  0x00000000005176c9 in
>>> gold::Gdb_index_info_reader::read_pubnames_and_pubtypes
>>> (this=0x7fffffff5a30, die=0x7fffffff5960) at gdb-index.cc:942
>>> #3  0x0000000000518009 in gold::Gdb_index_info_reader::visit_top_die (
>>>      this=0x7fffffff5a30, die=0x7fffffff5960) at gdb-index.cc:379
>>> #4  0x00000000005180d3 in
>>> gold::Gdb_index_info_reader::visit_compilation_unit
>>>      (this=0x7fffffff5a30, cu_offset=<optimized out>,
>>>      cu_length=<optimized out>, root_die=<optimized out>) at
>>> gdb-index.cc:326
>>> #5  0x000000000062a8f2 in gold::Dwarf_info_reader::do_parse<false> (
>>>      this=this@entry=0x7fffffff5a30) at dwarf_reader.cc:1363
>>> #6  0x000000000062746e in gold::Dwarf_info_reader::parse (
>>>      this=this@entry=0x7fffffff5a30) at dwarf_reader.cc:1234
>>> #7  0x00000000005187b1 in gold::Gdb_index::scan_debug_info
>>> (this=0x901e90,
>>>      is_type_unit=is_type_unit@entry=false,
>>> object=object@entry=0x946f90,
>>>      symbols=0x2aaaaaaeb150 "", symbols@entry=0xb <Address 0xb out of
>>> bounds>,
>>>      symbols_size=symbols_size@entry=504, shndx=<optimized out>,
>>>      reloc_shndx=9, reloc_type=4) at gdb-index.cc:1119
>>> #8  0x0000000000550939 in gold::Layout::add_to_gdb_index<64, false> (
>>>      this=this@entry=0x7fffffff6f30,
>>> is_type_unit=is_type_unit@entry=false,
>>>      object=object@entry=0x946f90, symbols=0xb <Address 0xb out of
>>> bounds>,
>>>      symbols@entry=0x2aaaaaaeb150 "",
>>> symbols_size=symbols_size@entry=504,
>>>      shndx=<optimized out>, reloc_shndx=9, reloc_type=4) at
>>> layout.cc:1569
>>
>> In frame #8, the value of object->name_ would tell you which .o file
>> it's reading. If you can find this and send me a copy of that .o file,
>> I'd like to take a look at it. (Since you say this is actually a
>> fairly small link, you could just send me all the .o files.)
>
> I will try to do this. I know nothing about the innards of
> ld.gold and the suggestion about object->name_ is very helpful.
>
> And, if the total size of the objects don't add up too much, maybe I can
> send you the whole set after compressing them, etc.
>
> Thank you again for your help.
>
>>
>> -cary
>>
>
> Chiaki
>
>




More information about the Binutils mailing list