ld crashing (SIGSEGV)

We are experiencing a crash (SIGSEGV) of ld when trying to link several of
our C++ applications.
I have included below the command line and coreinfo output for one
particular example.

Any suggestions on how to start looking for a cause and/or fix?

We are running 6.1.

Rob Rutherford

Command line (newlines added for readability):

cc -vv -g -lang-c++ -M -L …/… -Wl,-( apptest.o app.lib
…/…/log_stderr.lib
…/…/timecode_posix.lib …/…/ipc.lib …/…/dsapi.lib …/…/global.lib
…/…/logmem.lib
…/…/shmem.lib -o apptest
/usr/ntox86/bin/ld -Map apptest.map -b elf32-i386 --dynamic-linker
/usr/lib/ldqnx.so.2
/x86/lib/crt1.o /x86/lib/crti.o /usr/lib/gcc-lib/ntox86/2.95.2/crtbeginC++.o
-L…/… -( apptest.o app.lib …/…/log_stderr.lib …/…/timecode_posix.lib
…/…/ipc.lib
…/…/dsapi.lib …/…/global.lib …/…/logmem.lib …/…/shmem.lib -o apptest
-Y/x86/lib:/x86/usr/lib -L/usr/lib/gcc-lib/ntox86/2.95.2/exceptions -L/usr/n
tox86/lib/exceptions
-L/usr/ntox86/lib -lcpp -lm
/usr/lib/gcc-lib/ntox86/2.95.2/exceptions/libgcc.a
-lc -dn -Bstatic -lc /usr/lib/gcc-lib/ntox86/2.95.2/exceptions/libgcc.a
/usr/lib/gcc-lib/ntox86/2.95.2/crtendC++.o /x86/lib/crtn.o

coreinfo output:

/var/dumps/ld.core:
size=156 total_size=2280 system_private:off/size=464,104
asinfo:off/size=1480,480 meminfo:off/size=568,96 hwinfo:off/size=912,568
cpuinfo:off/size=376,32 cacheattr:off/size=2280,0 qtime:off/size=304,72
callout:off/size=160,72 callin:off/size=232,64 intrinfo:off/size=1960,320
typed_strings:off/size=664,32 strings:off/size=696,216
processor=X86 num_cpus=1
cpu 1 cpu=686 name=Pentium III Stepping 3 speed=547
flags=0xc0001fff FPU MMU CPUID RDTSC INVLPG WP BSWAP MMX CMOV PSE PGE
MTRR SEP SIMD FXSR
cyc/sec=547678500 tod_adj=998303116000000000 nsec=187365388708820
inc=999847
boot=998303116 epoch=1970 intr=0
rate=838095345 scale=-15 load=1193
MACHINE=“x86pc” HOSTNAME=“localhost”
hwflags=0x000540
valid=512 heads=240 cyls=832 sectors=63 nblocks=12564720 spare=0
pid=43913287 parent=43909188 child=0 pgrp=43884596 sid=8445993
flags=0x002000 umask=022 base_addr=0x8048000 init_stack=0x804758c
ruid=453 euid=453 suid=453 rgid=900 egid=900 sgid=900
ign=0000000000040000 queue=ff00000000000000 pending=0000000000000000
fds=14 threads=1 timers=0 chans=1
thread 1 SIGNALLED-SIGSEGV code=1 MAPERR refaddr=87dfa29 fltno=11
ip=0xb8219172 sp=0x8046f10 stkbase=0x7fc7000 stksize=528384
state=STOPPED flags=0 last_cpu=1 timeout=00000000
pri=9 realpri=9 policy=RR
Mapping 0x08045000-0x08048000 RW-
Mapping 0x08048000-0x080b4000 RWX
Mapping 0x080b4000-0x080b7000 RWX
Mapping 0x080b7000-0x08677000 RW-
Mapping 0xb0300000-0xb034a000 RWX
Mapping 0xb034a000-0xb034e000 RWX
Mapping 0xb8200000-0xb82a0000 RWX
Mapping 0xb82a0000-0xb82ac000 RWX

It may be running out of stack.

Try doing

ldrel -L -S 1024000 /usr/bin/ld

Also, it may be related to your use of the library grouping args. You might
try just including the libs multiple times when necessary.

Robert Rutherford <ruzz@ruzz.com> wrote:

We are experiencing a crash (SIGSEGV) of ld when trying to link several of
our C++ applications.
I have included below the command line and coreinfo output for one
particular example.

Any suggestions on how to start looking for a cause and/or fix?

We are running 6.1.

Rob Rutherford

Command line (newlines added for readability):

cc -vv -g -lang-c++ -M -L …/… -Wl,-( apptest.o app.lib
…/…/log_stderr.lib
…/…/timecode_posix.lib …/…/ipc.lib …/…/dsapi.lib …/…/global.lib
…/…/logmem.lib
…/…/shmem.lib -o apptest
/usr/ntox86/bin/ld -Map apptest.map -b elf32-i386 --dynamic-linker
/usr/lib/ldqnx.so.2
/x86/lib/crt1.o /x86/lib/crti.o /usr/lib/gcc-lib/ntox86/2.95.2/crtbeginC++.o
-L…/… -( apptest.o app.lib …/…/log_stderr.lib …/…/timecode_posix.lib
…/…/ipc.lib
…/…/dsapi.lib …/…/global.lib …/…/logmem.lib …/…/shmem.lib -o apptest
-Y/x86/lib:/x86/usr/lib -L/usr/lib/gcc-lib/ntox86/2.95.2/exceptions -L/usr/n
tox86/lib/exceptions
-L/usr/ntox86/lib -lcpp -lm
/usr/lib/gcc-lib/ntox86/2.95.2/exceptions/libgcc.a
-lc -dn -Bstatic -lc /usr/lib/gcc-lib/ntox86/2.95.2/exceptions/libgcc.a
/usr/lib/gcc-lib/ntox86/2.95.2/crtendC++.o /x86/lib/crtn.o

coreinfo output:

/var/dumps/ld.core:
size=156 total_size=2280 system_private:off/size=464,104
asinfo:off/size=1480,480 meminfo:off/size=568,96 hwinfo:off/size=912,568
cpuinfo:off/size=376,32 cacheattr:off/size=2280,0 qtime:off/size=304,72
callout:off/size=160,72 callin:off/size=232,64 intrinfo:off/size=1960,320
typed_strings:off/size=664,32 strings:off/size=696,216
processor=X86 num_cpus=1
cpu 1 cpu=686 name=Pentium III Stepping 3 speed=547
flags=0xc0001fff FPU MMU CPUID RDTSC INVLPG WP BSWAP MMX CMOV PSE PGE
MTRR SEP SIMD FXSR
cyc/sec=547678500 tod_adj=998303116000000000 nsec=187365388708820
inc=999847
boot=998303116 epoch=1970 intr=0
rate=838095345 scale=-15 load=1193
MACHINE=“x86pc” HOSTNAME=“localhost”
hwflags=0x000540
valid=512 heads=240 cyls=832 sectors=63 nblocks=12564720 spare=0
pid=43913287 parent=43909188 child=0 pgrp=43884596 sid=8445993
flags=0x002000 umask=022 base_addr=0x8048000 init_stack=0x804758c
ruid=453 euid=453 suid=453 rgid=900 egid=900 sgid=900
ign=0000000000040000 queue=ff00000000000000 pending=0000000000000000
fds=14 threads=1 timers=0 chans=1
thread 1 SIGNALLED-SIGSEGV code=1 MAPERR refaddr=87dfa29 fltno=11
ip=0xb8219172 sp=0x8046f10 stkbase=0x7fc7000 stksize=528384
state=STOPPED flags=0 last_cpu=1 timeout=00000000
pri=9 realpri=9 policy=RR
Mapping 0x08045000-0x08048000 RW-
Mapping 0x08048000-0x080b4000 RWX
Mapping 0x080b4000-0x080b7000 RWX
Mapping 0x080b7000-0x08677000 RW-
Mapping 0xb0300000-0xb034a000 RWX
Mapping 0xb034a000-0xb034e000 RWX
Mapping 0xb8200000-0xb82a0000 RWX
Mapping 0xb82a0000-0xb82ac000 RWX


cburgess@qnx.com

I have some further information:

  • I tried both of Colin’s suggestions with no luck. It still crashes. I even
    tried increasing the stack to 4MB.
  • By trial and error, I discovered that the problem was caused by a missing
    library on the command line, leading to unresolved symbols.

So, the good news is that we can link our applications and carry on with our
work.

But the bad news is that it looks like there is a problem with ld that
(sometimes) causes it to SIGSEGV if there are unresolved symbols.

Robert

“Colin Burgess” <cburgess@qnx.com> wrote in message
news:9m0cj9$qiv$2@nntp.qnx.com

It may be running out of stack.

Try doing

ldrel -L -S 1024000 /usr/bin/ld

Also, it may be related to your use of the library grouping args. You
might
try just including the libs multiple times when necessary.

Robert Rutherford <> ruzz@ruzz.com> > wrote:
We are experiencing a crash (SIGSEGV) of ld when trying to link several
of
our C++ applications.
I have included below the command line and coreinfo output for one
particular example.

Any suggestions on how to start looking for a cause and/or fix?

We are running 6.1.

Rob Rutherford

Command line (newlines added for readability):

cc -vv -g -lang-c++ -M -L …/… -Wl,-( apptest.o app.lib
…/…/log_stderr.lib
…/…/timecode_posix.lib …/…/ipc.lib …/…/dsapi.lib …/…/global.lib
…/…/logmem.lib
…/…/shmem.lib -o apptest
/usr/ntox86/bin/ld -Map apptest.map -b elf32-i386 --dynamic-linker
/usr/lib/ldqnx.so.2
/x86/lib/crt1.o /x86/lib/crti.o
/usr/lib/gcc-lib/ntox86/2.95.2/crtbeginC++.o
-L…/… -( apptest.o app.lib …/…/log_stderr.lib
…/…/timecode_posix.lib
…/…/ipc.lib
…/…/dsapi.lib …/…/global.lib …/…/logmem.lib …/…/shmem.lib -o
apptest

-Y/x86/lib:/x86/usr/lib -L/usr/lib/gcc-lib/ntox86/2.95.2/exceptions -L/usr
/n
tox86/lib/exceptions
-L/usr/ntox86/lib -lcpp -lm
/usr/lib/gcc-lib/ntox86/2.95.2/exceptions/libgcc.a
-lc -dn -Bstatic -lc /usr/lib/gcc-lib/ntox86/2.95.2/exceptions/libgcc.a
/usr/lib/gcc-lib/ntox86/2.95.2/crtendC++.o /x86/lib/crtn.o

coreinfo output:

/var/dumps/ld.core:
size=156 total_size=2280 system_private:off/size=464,104
asinfo:off/size=1480,480 meminfo:off/size=568,96
hwinfo:off/size=912,568
cpuinfo:off/size=376,32 cacheattr:off/size=2280,0 qtime:off/size=304,72
callout:off/size=160,72 callin:off/size=232,64
intrinfo:off/size=1960,320
typed_strings:off/size=664,32 strings:off/size=696,216
processor=X86 num_cpus=1
cpu 1 cpu=686 name=Pentium III Stepping 3 speed=547
flags=0xc0001fff FPU MMU CPUID RDTSC INVLPG WP BSWAP MMX CMOV PSE PGE
MTRR SEP SIMD FXSR
cyc/sec=547678500 tod_adj=998303116000000000 nsec=187365388708820
inc=999847
boot=998303116 epoch=1970 intr=0
rate=838095345 scale=-15 load=1193
MACHINE=“x86pc” HOSTNAME=“localhost”
hwflags=0x000540
valid=512 heads=240 cyls=832 sectors=63 nblocks=12564720 spare=0
pid=43913287 parent=43909188 child=0 pgrp=43884596 sid=8445993
flags=0x002000 umask=022 base_addr=0x8048000 init_stack=0x804758c
ruid=453 euid=453 suid=453 rgid=900 egid=900 sgid=900
ign=0000000000040000 queue=ff00000000000000 pending=0000000000000000
fds=14 threads=1 timers=0 chans=1
thread 1 SIGNALLED-SIGSEGV code=1 MAPERR refaddr=87dfa29 fltno=11
ip=0xb8219172 sp=0x8046f10 stkbase=0x7fc7000 stksize=528384
state=STOPPED flags=0 last_cpu=1 timeout=00000000
pri=9 realpri=9 policy=RR
Mapping 0x08045000-0x08048000 RW-
Mapping 0x08048000-0x080b4000 RWX
Mapping 0x080b4000-0x080b7000 RWX
Mapping 0x080b7000-0x08677000 RW-
Mapping 0xb0300000-0xb034a000 RWX
Mapping 0xb034a000-0xb034e000 RWX
Mapping 0xb8200000-0xb82a0000 RWX
Mapping 0xb82a0000-0xb82ac000 RWX



\

cburgess@qnx.com

I fixed a bug way back in may that would cause ld to crash if you
had undefined references in a dwarf-1 debug module. This appears
to be in the 6.1 tools (on my system at least)

so…

  1. are you sure you upgraded the tools? Does ld --version show
    GNU ld 2.10.1
    Copyright 2000 Free Software Foundation, Inc.
    This program is free software; you may redistribute it under the terms of
    the GNU General Public License. This program has absolutely no warranty.
    Supported emulations:
    i386nto
    elf32ppcnto
    elf32bmipnto
    armnto
    shelf_nto
    shlelf_nto

  2. if you change to using dwarf-2 (-gdwarf-2) does the problem
    disappear?

Robert Rutherford <ruzz@ruzz.com> wrote:

I have some further information:

  • I tried both of Colin’s suggestions with no luck. It still crashes. I even
    tried increasing the stack to 4MB.
  • By trial and error, I discovered that the problem was caused by a missing
    library on the command line, leading to unresolved symbols.

So, the good news is that we can link our applications and carry on with our
work.

But the bad news is that it looks like there is a problem with ld that
(sometimes) causes it to SIGSEGV if there are unresolved symbols.

Robert

“Colin Burgess” <> cburgess@qnx.com> > wrote in message
news:9m0cj9$qiv$> 2@nntp.qnx.com> …
It may be running out of stack.

Try doing

ldrel -L -S 1024000 /usr/bin/ld

Also, it may be related to your use of the library grouping args. You
might
try just including the libs multiple times when necessary.

Robert Rutherford <> ruzz@ruzz.com> > wrote:
We are experiencing a crash (SIGSEGV) of ld when trying to link several
of
our C++ applications.
I have included below the command line and coreinfo output for one
particular example.

Any suggestions on how to start looking for a cause and/or fix?

We are running 6.1.

Rob Rutherford

Command line (newlines added for readability):

cc -vv -g -lang-c++ -M -L …/… -Wl,-( apptest.o app.lib
…/…/log_stderr.lib
…/…/timecode_posix.lib …/…/ipc.lib …/…/dsapi.lib …/…/global.lib
…/…/logmem.lib
…/…/shmem.lib -o apptest
/usr/ntox86/bin/ld -Map apptest.map -b elf32-i386 --dynamic-linker
/usr/lib/ldqnx.so.2
/x86/lib/crt1.o /x86/lib/crti.o
/usr/lib/gcc-lib/ntox86/2.95.2/crtbeginC++.o
-L…/… -( apptest.o app.lib …/…/log_stderr.lib
…/…/timecode_posix.lib
…/…/ipc.lib
…/…/dsapi.lib …/…/global.lib …/…/logmem.lib …/…/shmem.lib -o
apptest

-Y/x86/lib:/x86/usr/lib -L/usr/lib/gcc-lib/ntox86/2.95.2/exceptions -L/usr
/n
tox86/lib/exceptions
-L/usr/ntox86/lib -lcpp -lm
/usr/lib/gcc-lib/ntox86/2.95.2/exceptions/libgcc.a
-lc -dn -Bstatic -lc /usr/lib/gcc-lib/ntox86/2.95.2/exceptions/libgcc.a
/usr/lib/gcc-lib/ntox86/2.95.2/crtendC++.o /x86/lib/crtn.o

coreinfo output:

/var/dumps/ld.core:
size=156 total_size=2280 system_private:off/size=464,104
asinfo:off/size=1480,480 meminfo:off/size=568,96
hwinfo:off/size=912,568
cpuinfo:off/size=376,32 cacheattr:off/size=2280,0 qtime:off/size=304,72
callout:off/size=160,72 callin:off/size=232,64
intrinfo:off/size=1960,320
typed_strings:off/size=664,32 strings:off/size=696,216
processor=X86 num_cpus=1
cpu 1 cpu=686 name=Pentium III Stepping 3 speed=547
flags=0xc0001fff FPU MMU CPUID RDTSC INVLPG WP BSWAP MMX CMOV PSE PGE
MTRR SEP SIMD FXSR
cyc/sec=547678500 tod_adj=998303116000000000 nsec=187365388708820
inc=999847
boot=998303116 epoch=1970 intr=0
rate=838095345 scale=-15 load=1193
MACHINE=“x86pc” HOSTNAME=“localhost”
hwflags=0x000540
valid=512 heads=240 cyls=832 sectors=63 nblocks=12564720 spare=0
pid=43913287 parent=43909188 child=0 pgrp=43884596 sid=8445993
flags=0x002000 umask=022 base_addr=0x8048000 init_stack=0x804758c
ruid=453 euid=453 suid=453 rgid=900 egid=900 sgid=900
ign=0000000000040000 queue=ff00000000000000 pending=0000000000000000
fds=14 threads=1 timers=0 chans=1
thread 1 SIGNALLED-SIGSEGV code=1 MAPERR refaddr=87dfa29 fltno=11
ip=0xb8219172 sp=0x8046f10 stkbase=0x7fc7000 stksize=528384
state=STOPPED flags=0 last_cpu=1 timeout=00000000
pri=9 realpri=9 policy=RR
Mapping 0x08045000-0x08048000 RW-
Mapping 0x08048000-0x080b4000 RWX
Mapping 0x080b4000-0x080b7000 RWX
Mapping 0x080b7000-0x08677000 RW-
Mapping 0xb0300000-0xb034a000 RWX
Mapping 0xb034a000-0xb034e000 RWX
Mapping 0xb8200000-0xb82a0000 RWX
Mapping 0xb82a0000-0xb82ac000 RWX



\

cburgess@qnx.com


cburgess@qnx.com

  1. are you sure you upgraded the tools? Does ld --version show
    GNU ld 2.10.1
    Copyright 2000 Free Software Foundation, Inc.
    [more trimmed]

Yes it shows exactly this message.

Our version of ld is 445712 bytes dated Jun 26 05:08

  1. if you change to using dwarf-2 (-gdwarf-2) does the problem
    disappear?

Yes! We are happy now (and will use dwarf-2 for everything, unless there is
a reason not to??)

Do you want any more information to track down this problem?

Robert

Robert Rutherford <> ruzz@ruzz.com> > wrote:
I have some further information:

  • I tried both of Colin’s suggestions with no luck. It still crashes. I
    even
    tried increasing the stack to 4MB.
  • By trial and error, I discovered that the problem was caused by a
    missing
    library on the command line, leading to unresolved symbols.

So, the good news is that we can link our applications and carry on with
our
work.

But the bad news is that it looks like there is a problem with ld that
(sometimes) causes it to SIGSEGV if there are unresolved symbols.

Robert

“Colin Burgess” <> cburgess@qnx.com> > wrote in message
news:9m0cj9$qiv$> 2@nntp.qnx.com> …
It may be running out of stack.

Try doing

ldrel -L -S 1024000 /usr/bin/ld

Also, it may be related to your use of the library grouping args. You
might
try just including the libs multiple times when necessary.

Robert Rutherford <> ruzz@ruzz.com> > wrote:
We are experiencing a crash (SIGSEGV) of ld when trying to link
several
of
our C++ applications.
I have included below the command line and coreinfo output for one
particular example.

Any suggestions on how to start looking for a cause and/or fix?

We are running 6.1.

Rob Rutherford

Command line (newlines added for readability):

cc -vv -g -lang-c++ -M -L …/… -Wl,-( apptest.o app.lib
…/…/log_stderr.lib
…/…/timecode_posix.lib …/…/ipc.lib …/…/dsapi.lib
…/…/global.lib
…/…/logmem.lib
…/…/shmem.lib -o apptest
/usr/ntox86/bin/ld -Map apptest.map -b elf32-i386 --dynamic-linker
/usr/lib/ldqnx.so.2
/x86/lib/crt1.o /x86/lib/crti.o
/usr/lib/gcc-lib/ntox86/2.95.2/crtbeginC++.o
-L…/… -( apptest.o app.lib …/…/log_stderr.lib
…/…/timecode_posix.lib
…/…/ipc.lib
…/…/dsapi.lib …/…/global.lib …/…/logmem.lib …/…/shmem.lib -o
apptest


-Y/x86/lib:/x86/usr/lib -L/usr/lib/gcc-lib/ntox86/2.95.2/exceptions -L/us
r
/n
tox86/lib/exceptions
-L/usr/ntox86/lib -lcpp -lm
/usr/lib/gcc-lib/ntox86/2.95.2/exceptions/libgcc.a
-lc -dn -Bstatic -lc
/usr/lib/gcc-lib/ntox86/2.95.2/exceptions/libgcc.a
/usr/lib/gcc-lib/ntox86/2.95.2/crtendC++.o /x86/lib/crtn.o

coreinfo output:

/var/dumps/ld.core:
size=156 total_size=2280 system_private:off/size=464,104
asinfo:off/size=1480,480 meminfo:off/size=568,96
hwinfo:off/size=912,568
cpuinfo:off/size=376,32 cacheattr:off/size=2280,0
qtime:off/size=304,72
callout:off/size=160,72 callin:off/size=232,64
intrinfo:off/size=1960,320
typed_strings:off/size=664,32 strings:off/size=696,216
processor=X86 num_cpus=1
cpu 1 cpu=686 name=Pentium III Stepping 3 speed=547
flags=0xc0001fff FPU MMU CPUID RDTSC INVLPG WP BSWAP MMX CMOV PSE
PGE
MTRR SEP SIMD FXSR
cyc/sec=547678500 tod_adj=998303116000000000 nsec=187365388708820
inc=999847
boot=998303116 epoch=1970 intr=0
rate=838095345 scale=-15 load=1193
MACHINE=“x86pc” HOSTNAME=“localhost”
hwflags=0x000540
valid=512 heads=240 cyls=832 sectors=63 nblocks=12564720 spare=0
pid=43913287 parent=43909188 child=0 pgrp=43884596 sid=8445993
flags=0x002000 umask=022 base_addr=0x8048000 init_stack=0x804758c
ruid=453 euid=453 suid=453 rgid=900 egid=900 sgid=900
ign=0000000000040000 queue=ff00000000000000 pending=0000000000000000
fds=14 threads=1 timers=0 chans=1
thread 1 SIGNALLED-SIGSEGV code=1 MAPERR refaddr=87dfa29 fltno=11
ip=0xb8219172 sp=0x8046f10 stkbase=0x7fc7000 stksize=528384
state=STOPPED flags=0 last_cpu=1 timeout=00000000
pri=9 realpri=9 policy=RR
Mapping 0x08045000-0x08048000 RW-
Mapping 0x08048000-0x080b4000 RWX
Mapping 0x080b4000-0x080b7000 RWX
Mapping 0x080b7000-0x08677000 RW-
Mapping 0xb0300000-0xb034a000 RWX
Mapping 0xb034a000-0xb034e000 RWX
Mapping 0xb8200000-0xb82a0000 RWX
Mapping 0xb82a0000-0xb82ac000 RWX



\

cburgess@qnx.com


\

cburgess@qnx.com