Bug 2735 - Segmentation fault in bfd.c during error handling
Summary: Segmentation fault in bfd.c during error handling
Alias: None
Product: binutils
Classification: Unclassified
Component: binutils (show other bugs)
Version: 2.16
: P2 normal
Target Milestone: ---
Assignee: unassigned
Depends on:
Reported: 2006-06-08 18:36 UTC by Asher Langton
Modified: 2006-06-12 11:18 UTC (History)
1 user (show)

See Also:
Host: i686-pc-linux
Target: i686-pc-linux
Build: i686-pc-linux
Last reconfirmed:

Handle case where common alignment is deduced from section alginment and not another common defintion (1.28 KB, patch)
2006-06-09 13:37 UTC, Nick Clifton
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Asher Langton 2006-06-08 18:36:53 UTC
ld version 2.16.1 crashes due to a null pointer when trying to report a warning
related to a gcc object file compiled with -fopenmp.  The offending line in
2.16.1 is bfd.c:481, where abfd is NULL:

if (p[1] == 'B')
    bfd *abfd = va_arg (ap, bfd *);
    if (abfd->my_archive)
      snprintf (bufp, avail, "%s(%s)",
                abfd->my_archive->filename, abfd->filename);

This bug can be reproduced using as follows, using the 2 files ctp.c and
csimple.c, and gcc 4.2.0 20060601.  (The ld -r line is necessary here.)

(776)% cat ctp.c
float matrix;

void ctp()
#pragma omp threadprivate(matrix)
  matrix = 0.0;
(777)% cat csimple.c 
void ctp();

int main()
  return 0;
(778)% gcc -fopenmp -c ctp.c
(779)% ld -r ctp.o -o ctpr.o
(780)% gcc -fopenmp csimple.c ctp.o
(781)% gcc -fopenmp csimple.c ctpr.o
collect2: ld terminated with signal 11 [Segmentation fault], core dumped
ld: (782)% 

I modified bfd.c so I could get the error message that should have been printed,
which was:

(792)% gcc -fopenmp csimple.c ctpr.o
ld: Warning: alignment 1 of symbol `matrix' in
abfd->my_archive->filename(abfd->filename) is smaller than 4 in ctpr.o
Comment 1 Nick Clifton 2006-06-09 13:36:44 UTC
Hi Asher,

  The problem appears to be that the .tcommon section has an alignment of 1
whereas the "matrix" symbol has an alignment of 4.

  The code to generate the warning message was not taking into account the fact
that this situation could be encountered, and so it was assuming that there
would always be another input file that contained a second defintion of the
common symbol, but with a different alignment requirement.  The uploaded patch
should resolve this problem though.  Please could you try it and let us know if
you encounter any problems with it ?

Comment 2 Nick Clifton 2006-06-09 13:37:36 UTC
Created attachment 1069 [details]
Handle case where common alignment is deduced from section alginment and not another common defintion
Comment 3 Asher Langton 2006-06-09 23:59:25 UTC
Yes, this patch fixes the problem.  Thanks!
Comment 4 Nick Clifton 2006-06-12 11:18:59 UTC
Patch applied.