Bug 12730 - [regression] crash when allocating in a static constructor
Summary: [regression] crash when allocating in a static constructor
Status: RESOLVED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: 2.22
: P2 normal
Target Milestone: ---
Assignee: unassigned
URL: http://sourceware.org/ml/binutils/201...
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-04 18:19 UTC by Matthias Klose
Modified: 2011-05-19 14:51 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
Test program to demonstrate allocate crash (304 bytes, text/plain)
2011-05-16 13:34 UTC, Craig Southeren
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Klose 2011-05-04 18:19:07 UTC
[forwarded from http://bugs.debian.org/625616]

segfaults with trunk 20110501, works with 2.21 branch 20110327, works with gold.

$ g++ test.cxx && ./a.out 
Segmentation fault
$ cat test.cxx
#include <iostream>
#include <ext/bitmap_allocator.h>

class Hello
{
public:
   Hello ()
    {}

  ~Hello ()
    {}

  void act ()
    { std::cout << "Hello, world!" << std::endl; }
};

static void __attribute__ (( constructor )) PWLIB_StaticLoader() { \
  __gnu_cxx::bitmap_allocator<Hello> allocator; \
  Hello* salut = allocator._M_allocate_single_object (); \
  salut->act (); \
}


int
main (int /*argc*/,
      char* /*argv*/[])
{
  return 0;
}
Comment 1 Matthias Klose 2011-05-04 18:31:27 UTC
succeeds with both gold from 2.21 and trunk
Comment 2 H.J. Lu 2011-05-04 22:42:49 UTC
The behavior of this testcase depends on the order of

__static_initialization_and_destruction_0(int, int)

and

PWLIB_StaticLoader ()

PWLIB_StaticLoader must be called after __static_initialization_and_destruction_0.

Depending on compiler and linker, the relative order may be different.
I will change the linker to preserve the order.
Comment 3 H.J. Lu 2011-05-05 05:20:36 UTC
A patch is posted at

http://sourceware.org/ml/binutils/2011-05/msg00060.html
Comment 4 cvs-commit@gcc.gnu.org 2011-05-07 14:13:06 UTC
CVSROOT:	/cvs/src
Module name:	src
Changes by:	hjl@sourceware.org	2011-05-07 14:13:00

Modified files:
	ld/testsuite   : ChangeLog 
	ld/testsuite/ld-elf: elf.exp init-mixed.c 
	bfd            : ChangeLog bfd-in2.h elf.c elflink.c section.c 
Added files:
	ld/testsuite/ld-elf: pr12730.cc pr12730.out 

Log message:
	Reverse copy .ctors/.dtors sections if needed.
	
	bfd/
	
	2011-05-07  H.J. Lu  <hongjiu.lu@intel.com>
	
	PR ld/12730
	* elf.c (_bfd_elf_section_offset): Check SEC_ELF_REVERSE_COPY.
	
	* elflink.c (elf_link_input_bfd): Reverse copy .ctors/.dtors
	sections if needed.
	
	* section.c (SEC_ELF_REVERSE_COPY): New.
	* bfd-in2.h: Regenerated.
	
	ld/testsuite/
	
	2011-05-07  H.J. Lu  <hongjiu.lu@intel.com>
	
	PR ld/12730
	* ld-elf/elf.exp (array_tests): Add "pr12730".
	(array_tests_pie): New.
	(array_tests_static): Add -static for "static init array mixed".
	Add "static pr12730".  Run array_tests_pie for Linux.
	
	* ld-elf/init-mixed.c (ctor1007): Renamed to ...
	(ctor1007a): This.
	(ctor1007b): New.
	(ctors1007): Remove ctor1007.  Add ctor1007b and ctor1007a.
	(dtor1007): Renamed to ...
	(dtor1007a): This.
	(dtor1007b): New.
	(dtors1007): Remove dtor1007.  Add dtor1007b and dtor1007a.
	(ctor65535): Renamed to ...
	(ctor65535a): This.
	(ctor65535b): New.
	(ctors65535): Remove ctor65535.  Add ctor65535b and ctor65535a.
	(dtor65535): Renamed to ...
	(dtor65535a): This.
	(dtor65535b): New.
	(dtors65535): Remove dtor65535.  Add dtor65535b and dtor65535a.
	
	* ld-elf/pr12730.cc: New.
	* ld-elf/pr12730.out: Likewise.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/testsuite/ChangeLog.diff?cvsroot=src&r1=1.1396&r2=1.1397
http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/testsuite/ld-elf/pr12730.cc.diff?cvsroot=src&r1=NONE&r2=1.1
http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/testsuite/ld-elf/pr12730.out.diff?cvsroot=src&r1=NONE&r2=1.1
http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/testsuite/ld-elf/elf.exp.diff?cvsroot=src&r1=1.20&r2=1.21
http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/testsuite/ld-elf/init-mixed.c.diff?cvsroot=src&r1=1.1&r2=1.2
http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/ChangeLog.diff?cvsroot=src&r1=1.5332&r2=1.5333
http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/bfd-in2.h.diff?cvsroot=src&r1=1.535&r2=1.536
http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/elf.c.diff?cvsroot=src&r1=1.533&r2=1.534
http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/elflink.c.diff?cvsroot=src&r1=1.402&r2=1.403
http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/section.c.diff?cvsroot=src&r1=1.109&r2=1.110
Comment 5 Eugen Dedu 2011-05-13 21:21:38 UTC
It turns out that the fix was only partial.  With the fix, I have finally been able to reproduce the crash with two files.

$ cat >a.cxx
#include <iostream>

class Hello
{
public:
   Hello () {}
  ~Hello () {}
  void act (void);
};

void Hello::act (void)
{
  std::cout << "Hello, world!" << std::endl;
}

$ cat >aa.cxx
#include <ext/bitmap_allocator.h>
class Hello
{
public:
  Hello ();
  ~Hello ();
  void act (void);
};

static void __attribute__ (( constructor )) PWLIB_StaticLoader() {
  __gnu_cxx::bitmap_allocator<Hello> allocator;
  Hello* salut = allocator._M_allocate_single_object ();
  salut->act ();
}

int main (void)
{
  return 0;
}

$ g++ aa.cxx a.cxx
$ ./a.out
Segmentation fault

By chance, I discovered that the order of compilation is important:
$ g++ a.cxx aa.cxx
$ ./a.out
Hello, world!

Cheers,
Eugen
Comment 6 H.J. Lu 2011-05-13 22:22:51 UTC
(In reply to comment #5)
> It turns out that the fix was only partial.  With the fix, I have finally been
> able to reproduce the crash with two files.
> 

See:

http://sourceware.org/ml/binutils/2011-05/msg00105.html
Comment 7 Craig Southeren 2011-05-16 13:34:21 UTC
Created attachment 5728 [details]
Test program to demonstrate allocate crash
Comment 8 Craig Southeren 2011-05-16 13:35:47 UTC
Attached program exhibits crash when bitmap_allocate is used, but executes successfully for mt_thread and std:allocator
Comment 9 H.J. Lu 2011-05-17 02:46:32 UTC
(In reply to comment #7)
> Created attachment 5728 [details]
> Test program to demonstrate allocate crash

I don't think it is a linker problem.  Please report it to GCC.
Comment 10 Eugen Dedu 2011-05-19 14:51:25 UTC
(In reply to comment #9)
> (In reply to comment #7)
> > Created attachment 5728 [details]
> > Test program to demonstrate allocate crash
> 
> I don't think it is a linker problem.  Please report it to GCC.

For info, the new bug report is found at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49037.