[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test

[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |NEW
           Assignee|bkoz at gcc dot gnu.org            |unassigned at gcc dot gnu.org

--- Comment #23 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Unassigning since Benjamin since not been active in GCC development for over 8
years now.

[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING

--- Comment #24 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Dave, is this still an issue on the currently supported hp-ux targets?

[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test

[danglin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094

John David Anglin <danglin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |FIXED

--- Comment #25 from John David Anglin <danglin at gcc dot gnu.org> ---
No.

[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094

--- Comment #26 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Thanks!

[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test

[danglin at gcc dot gnu dot org]

------- Comment #22 from danglin at gcc dot gnu dot org  2009-07-30 20:23 -------
The following two tests also fail on hppa2.0w-hp-hpux11.11:

FAIL: ext/new_allocator/deallocate_global.cc execution test
FAIL: ext/throw_allocator/deallocate_global.cc execution test


-- 

danglin at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  GCC build triplet|hppa64-hp-hpux11.11         |hppa*-hp-hpux*
   GCC host triplet|hppa64-hp-hpux11.11         |hppa*-hp-hpux*
 GCC target triplet|hppa64-hp-hpux11.11         |hppa*-hp-hpux*


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094

[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test

[bkoz at gcc dot gnu dot org]

------- Comment #21 from bkoz at gcc dot gnu dot org  2009-05-29 01:20 -------

Yeah Paolo, didn't these this was due to your rework. I think the test cases
are ok now, seems like a better starting place although we may need to add 

// { dg-require-cxa-atexit "" }

on more of these. 

Actually had another idea about reworking throw_allocator, as attached for
trunk at some point. Although hackish, the current version's weird linkage gets
the job done without exports so don't see any need to mess with 4.4 branch. 

My plan is to work through the testsuite failures first and then when that dust
settles down then merge in the reworked throw_allocator.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094

[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test

[bkoz at gcc dot gnu dot org]

------- Comment #20 from bkoz at gcc dot gnu dot org  2009-05-29 01:13 -------
Created an attachment (id=17929)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17929&action=view)
reworked version of throw_allocator


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094

[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test

[paolo dot carlini at oracle dot com]

------- Comment #19 from paolo dot carlini at oracle dot com  2009-05-28 22:25 -------
Let's see what Benjamin eventually figures out: he has a lot of experience with
such nasty ordering issues... ;)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094

[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #18 from dave at hiauly1 dot hia dot nrc dot ca  2009-05-28 20:15 -------
Subject: Re:  FAIL: ext/throw_allocator/deallocate_global.cc execution test

> At least, now we are sure the issue was not caused by my tentative fixes to
> throw_allocator.

My conclusion was that this is a target bug involving the ordering
of atexit and static destructors.  The C++ standard apparently requires
that these be interleaved based on the order of registration.  I don't
think it would be possible to achieve full compliance because of the
limited capability of atexit, but it might be possible to change the
ordering.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094

[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test

[paolo dot carlini at oracle dot com]

------- Comment #17 from paolo dot carlini at oracle dot com  2009-05-28 20:09 -------
Sorry.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |bkoz at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094

[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test

[paolo dot carlini at oracle dot com]

------- Comment #16 from paolo dot carlini at oracle dot com  2009-05-28 19:59 -------
At least, now we are sure the issue was not caused by my tentative fixes to
throw_allocator.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|bkoz at gcc dot gnu dot org |unassigned at gcc dot gnu
                   |                            |dot org
             Status|ASSIGNED                    |NEW


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094

[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test

[bkoz at gcc dot gnu dot org]

------- Comment #14 from bkoz at gcc dot gnu dot org  2009-05-28 18:53 -------

Back, and on darwin as well.
http://gcc.gnu.org/ml/gcc-testresults/2009-05/msg02455.html
http://gcc.gnu.org/ml/gcc-testresults/2009-05/msg02457.html

Please hang on while I work through this.


-- 

bkoz at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|FIXED                       |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094

[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test

[bkoz at gcc dot gnu dot org]

------- Comment #15 from bkoz at gcc dot gnu dot org  2009-05-28 18:53 -------
Mine


-- 

bkoz at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |bkoz at gcc dot gnu dot org
                   |dot org                     |
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-05-28 18:53:40
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094

[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test

[danglin at gcc dot gnu dot org]

------- Comment #13 from danglin at gcc dot gnu dot org  2009-05-22 01:41 -------
I have the sense that this may be a constructor/destructor issue.  The
64-bit hpux target uses .init_array and .fini_array for this purpose.
The 32-bit hpux target uses a different mechanism.  I will check if the
32-bit target has the same problem.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094

[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test

[paolo at gcc dot gnu dot org]

------- Comment #12 from paolo at gcc dot gnu dot org  2009-05-22 01:33 -------
Subject: Bug 40094

Author: paolo
Date: Fri May 22 01:32:49 2009
New Revision: 147789

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147789
Log:
2009-05-21  Paolo Carlini  <paolo.carlini@oracle.com>

        PR libstdc++/40094
        Revert:
        2009-05-07  Paolo Carlini  <paolo.carlini@oracle.com>
        * include/ext/throw_allocator.h (throw_allocator_base): Avoid
        out of line member functions definitions.
        (throw_allocator_base::_S_g, _S_map, _S_throw_prob, _S_label):
        Remove, use static locals instead.
        (throw_allocator_base::do_check_allocated, print_to_string): Declare.
        * src/throw_allocator.cc: New.
        * src/Makefile.am: Add.
        * config/abi/pre/gnu.ver: Add exports.
        * src/Makefile.in: Regenerate.

Removed:
    trunk/libstdc++-v3/src/throw_allocator.cc


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094

[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test

[danglin at gcc dot gnu dot org]

------- Comment #11 from danglin at gcc dot gnu dot org  2009-05-22 01:30 -------
The first and second calls to delete free the same node:

Breakpoint 4, operator delete (p=0x800000010000e530)
Breakpoint 4, operator delete (p=0x800000010000e530)
Breakpoint 4, operator delete (p=0x800000010000e4f8)

Both the first and second calls appear to come from the same
hunk of code:

      // Erase without rebalancing.
      while (__x != 0)
        {
          _M_erase(_S_right(__x));
          _Link_type __y = _S_left(__x);
          _M_destroy_node(__x);
          __x = __y;
        }

The first time in, __y seems to point to garbage:

968               _M_destroy_node(__x);
(gdb) p __y
$13 = (_Link_type) 0xc000000000027eb3
(gdb) p *__y
$8 = {<std::_Rb_tree_node_base> = {_M_color = 22266430, 
    _M_parent = 0x37de3f0173c23f, _M_left = 0xe137de02802b7eef, 
    _M_right = 0xff73db3d81343f08}, _M_value_field = {
    first = 0x3417004273da3d, second = {first = 10464070018962284560, 
      second = 11029061579702265872}}}
(gdb) p *__x
$9 = {<std::_Rb_tree_node_base> = {_M_color = std::_S_black, 
    _M_parent = 0x8000000100002940, _M_left = 0x0, _M_right = 0x0}, 
  _M_value_field = {first = 0x800000010000e4f8, second = {first = 0, 
      second = 35}}}

__y points to something in the dynamic loader:

(gdb) info shared
>From                To                  Syms Read   Shared Object Library
0xc00000000000add0  0xc0000000000425e4  Yes         /usr/lib/pa20_64/dld.sl

This is the backtrace for the first call:

51        printf("operator delete is called \n");
(gdb) bt
#0  operator delete (p=0x800000010000e530) at deallocate_global.cc:51
#1  0x400000000000de94 in
__gnu_cxx::new_allocator<std::_Rb_tree_node<std::pair<void* const,
std::pair<unsigned long, unsigned long> > > >::deallocate (
    this=0x8000000100002938, __p=0x800000010000e530)
    at
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/ext/new_allocator.h:95
#2  0x400000000000d904 in std::_Rb_tree<void*, std::pair<void* const,
std::pair<unsigned long, unsigned long> >, std::_Select1st<std::pair<void*
const, std::pair<unsigned long, unsigned long> > >, std::less<void*>,
std::allocator<std::pair<void* const, std::pair<unsigned long, unsigned long> >
> >::_M_put_node (
    this=0x8000000100002938, __p=0x800000010000e530)
    at
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/stl_tree.h:363
#3  0x400000000000cf38 in std::_Rb_tree<void*, std::pair<void* const,
std::pair<unsigned long, unsigned long> >, std::_Select1st<std::pair<void*
const, std::pair<unsigned long, unsigned long> > >, std::less<void*>,
std::allocator<std::pair<void* const, std::pair<unsigned long, unsigned long> >
> >::_M_destroy_node
    (this=0x8000000100002938, __p=0x800000010000e530)
    at
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/stl_tree.h:384
#4  0x400000000000c124 in std::_Rb_tree<void*, std::pair<void* const,
std::pair<unsigned long, unsigned long> >, std::_Select1st<std::pair<void*
const, std::pair<unsigned long, unsigned long> > >, std::less<void*>,
std::allocator<std::pair<void* const, std::pair<unsigned long, unsigned long> >
> >::_M_erase (
    this=0x8000000100002938, __x=0x800000010000e530)
    at
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/stl_tree.h:968
#5  0x400000000000b440 in ~_Rb_tree (this=0x8000000100002938)
    at
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/stl_tree.h:614
#6  0x400000000000a1d8 in ~map (this=0x8000000100002938)
    at
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/stl_map.h:87
#7  0x400000000000a228 in __tcf_0 ()
    at
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/ext/throw_allocator.h:227
#8  0x800003fffdcd75d8 in exit () from /lib/pa20_64/libc.2
#9  0xc00000000000b394 in UT_exit () from /usr/lib/pa20_64/dld.sl
#10 0xc00000000000b3b4 in exit () from /usr/lib/pa20_64/dld.sl
#11 0xc00000000000b478 in $START$ () from /usr/lib/pa20_64/dld.sl


-- 

danglin at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.5.0                       |---


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094

[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test

[paolo at gcc dot gnu dot org]

------- Comment #9 from paolo at gcc dot gnu dot org  2009-05-22 01:29 -------
Subject: Bug 40094

Author: paolo
Date: Fri May 22 01:28:50 2009
New Revision: 147788

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147788
Log:
2009-05-21  Paolo Carlini  <paolo.carlini@oracle.com>

        PR libstdc++/40094
        Revert:
        2009-05-07  Paolo Carlini  <paolo.carlini@oracle.com>
        * include/ext/throw_allocator.h (throw_allocator_base): Avoid
        out of line member functions definitions.
        (throw_allocator_base::_S_g, _S_map, _S_throw_prob, _S_label):
        Remove, use static locals instead.
        (throw_allocator_base::do_check_allocated, print_to_string): Declare.
        * src/throw_allocator.cc: New.
        * src/Makefile.am: Add.
        * config/abi/pre/gnu.ver: Add exports.
        * src/Makefile.in: Regenerate.

Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/config/abi/pre/gnu.ver
    trunk/libstdc++-v3/configure
    trunk/libstdc++-v3/include/ext/throw_allocator.h
    trunk/libstdc++-v3/src/Makefile.am
    trunk/libstdc++-v3/src/Makefile.in
    trunk/libstdc++-v3/src/throw_allocator.cc


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094

[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test

[paolo dot carlini at oracle dot com]

------- Comment #10 from paolo dot carlini at oracle dot com  2009-05-22 01:29 -------
Fixes reverted.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094

[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test

[paolo dot carlini at oracle dot com]

------- Comment #8 from paolo dot carlini at oracle dot com  2009-05-22 01:15 -------
In any case, what you posted in the last comment looks to me very similar to
the *first* delete on linux, not the *second*. Maybe better if you post all
three deletes, one after the other.  Note: without my patch throw_allocator is
***badly*** broken, but I cannot debug something like this happening only on a
target which I don't have: thus, either you manage to ***really*** help here,
or I have to revert my fixes to throw_allocator and nobody is going to gain
anything from that.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094

[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test

[paolo dot carlini at oracle dot com]

------- Comment #7 from paolo dot carlini at oracle dot com  2009-05-22 01:07 -------
Any idea why this crazy thing is happening only on hpux?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094

[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test

[danglin at gcc dot gnu dot org]

------- Comment #6 from danglin at gcc dot gnu dot org  2009-05-22 00:54 -------
The backtrace from the second delete is:

(gdb) bt
#0  operator delete (p=0x800000010000e530) at deallocate_global.cc:51
#1  0x400000000000de94 in
__gnu_cxx::new_allocator<std::_Rb_tree_node<std::pair<void* const,
std::pair<unsigned long, unsigned long> > > >::deallocate (
    this=0x8000000100002938, __p=0x800000010000e530)
    at
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/ext/new_allocator.h:95
#2  0x400000000000d904 in std::_Rb_tree<void*, std::pair<void* const,
std::pair<unsigned long, unsigned long> >, std::_Select1st<std::pair<void*
const, std::pair<unsigned long, unsigned long> > >, std::less<void*>,
std::allocator<std::pair<void* const, std::pair<unsigned long, unsigned long> >
> >::_M_put_node (
    this=0x8000000100002938, __p=0x800000010000e530)
    at
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/stl_tree.h:363
#3  0x400000000000cf38 in std::_Rb_tree<void*, std::pair<void* const,
std::pair<unsigned long, unsigned long> >, std::_Select1st<std::pair<void*
const, std::pair<unsigned long, unsigned long> > >, std::less<void*>,
std::allocator<std::pair<void* const, std::pair<unsigned long, unsigned long> >
> >::_M_destroy_node
    (this=0x8000000100002938, __p=0x800000010000e530)
    at
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/stl_tree.h:384
#4  0x400000000000c124 in std::_Rb_tree<void*, std::pair<void* const,
std::pair<unsigned long, unsigned long> >, std::_Select1st<std::pair<void*
const, std::pair<unsigned long, unsigned long> > >, std::less<void*>,
std::allocator<std::pair<void* const, std::pair<unsigned long, unsigned long> >
> >::_M_erase (
    this=0x8000000100002938, __x=0x800000010000e530)
    at
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/stl_tree.h:968
#5  0x400000000000d488 in std::_Rb_tree<void*, std::pair<void* const,
std::pair<unsigned long, unsigned long> >, std::_Select1st<std::pair<void*
const, std::pair<unsigned long, unsigned long> > >, std::less<void*>,
std::allocator<std::pair<void* const, std::pair<unsigned long, unsigned long> >
> >::clear (
    this=0x8000000100002938)
    at
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/stl_tree.h:722
#6  0x400000000000cd28 in std::_Rb_tree<void*, std::pair<void* const,
std::pair<unsigned long, unsigned long> >, std::_Select1st<std::pair<void*
const, std::pair<unsigned long, unsigned long> > >, std::less<void*>,
std::allocator<std::pair<void* const, std::pair<unsigned long, unsigned long> >
> >::erase (
    this=0x8000000100002938, __first={_M_node = 0x800000010000e530}, __last=
      {_M_node = 0x8000000100002940})
    at
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/stl_tree.h:1377
#7  0x400000000000bef4 in std::_Rb_tree<void*, std::pair<void* const,
std::pair<unsigned long, unsigned long> >, std::_Select1st<std::pair<void*
const, std::pair<unsigned long, unsigned long> > >, std::less<void*>,
std::allocator<std::pair<void* const, std::pair<unsigned long, unsigned long> >
> >::erase (
    this=0x8000000100002938, __x=@0x800003fffdff0fe0)
    at
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/stl_tree.h:1366
#8  0x400000000000b210 in std::map<void*, std::pair<unsigned long, unsigned
long>, std::less<void*>, std::allocator<std::pair<void* const,
std::pair<unsigned long, unsigned long> > > >::erase (this=0x8000000100002938, 
    __x=@0x800000010000e530)
    at
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/stl_map.h:582
#9  0x4000000000009ea4 in __gnu_cxx::throw_allocator_base::erase (
    p=0x800000010000e4f8, size=35)
    at
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/ext/throw_allocator.h:180
#10 0x400000000000e8cc in __gnu_cxx::throw_allocator<char>::deallocate (
    this=0x800003fffdff0f20, __p=0x800000010000e4f8 "", __n=35)
    at
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/ext/throw_allocator.h:334
#11 0x400000000000e35c in std::basic_string<char, std::char_traits<char>,
__gnu_cxx::throw_allocator<char> >::_Rep::_M_destroy (this=0x800000010000e4f8, 
    __a=@0x800003fffdff0de8)
    at
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.tcc:426
#12 0x400000000000efe0 in std::basic_string<char, std::char_traits<char>,
__gnu_cxx::throw_allocator<char> >::_Rep::_M_dispose (this=0x800000010000e4f8, 
    __a=@0x800003fffdff0de8)
    at
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h:231
#13 0x400000000000ed6c in ~basic_string (this=0x8000000100001580)
    at
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h:498
#14 0x400000000000eca0 in __static_initialization_and_destruction_0 (
    __initialize_p=0, __priority=65535) at deallocate_global.cc:68
#15 0x400000000000f0a8 in global destructors keyed to _Znwm ()
    at deallocate_global.cc:73
#16 0x4000000000008bc4 in __do_global_dtors_aux ()
#17 0xc000000000032aa0 in TE_do_list#HLO_CL_#i1_0x0 ()
   from /usr/lib/pa20_64/dld.sl
#18 0xc00000000000d198 in TE_do_program_exit () from /usr/lib/pa20_64/dld.sl
#19 0x800003fffdcd762c in exit () from /lib/pa20_64/libc.2
#20 0xc00000000000b394 in UT_exit () from /usr/lib/pa20_64/dld.sl
#21 0xc00000000000b3b4 in exit () from /usr/lib/pa20_64/dld.sl
#22 0xc00000000000b478 in $START$ () from /usr/lib/pa20_64/dld.sl

      void
      deallocate(pointer __p, size_type __n)
      {
        erase(__p, sizeof(value_type) * __n);
        std::allocator<value_type>().deallocate(__p, __n);
      }

It originates from the call to erase in throw_allocator.h.  It would
appear that the call to delete arising from the call to erase is the
unexpected one. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094

[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test

[paolo dot carlini at oracle dot com]

------- Comment #5 from paolo dot carlini at oracle dot com  2009-05-21 09:15 -------
So, you should compare it to the previous delete, which normally should be the
*only* one involving basic_string.

To be clear, the expected sequence is the following, as you can check on any
other linux target:

operator new is called
operator new is called
operator delete is called
1 allocations to be released
operator delete is called
All memory released

that is, the additional delete / new pair that you are seeing at the end is
completely bogus.

Of course, I would suggest also checking what happens vs optimization level
(also for the *.so, thus rebuilding the library CXXFLAGS="-OX -g").


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094

[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test

[danglin at gcc dot gnu dot org]

------- Comment #4 from danglin at gcc dot gnu dot org  2009-05-21 00:49 -------
This is the backtrace for the last delete:

(gdb) bt
#0  operator delete (p=0x800000010000e4f8) at deallocate_global.cc:51
#1  0x400000000000eafc in __gnu_cxx::new_allocator<char>::deallocate (
    this=0x800003fffdff0fc8, __p=0x800000010000e4f8 "")
    at
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/ext/new_allocator.h:95
#2  0x400000000000e90c in __gnu_cxx::throw_allocator<char>::deallocate (
    this=0x800003fffdff0f20, __p=0x800000010000e4f8 "", __n=35)
    at
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/ext/throw_allocator.h:335
#3  0x400000000000e35c in std::basic_string<char, std::char_traits<char>,
__gnu_cxx::throw_allocator<char> >::_Rep::_M_destroy (this=0x800000010000e4f8, 
    __a=@0x800003fffdff0de8)
    at
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.tcc:426
#4  0x400000000000efe0 in std::basic_string<char, std::char_traits<char>,
__gnu_cxx::throw_allocator<char> >::_Rep::_M_dispose (this=0x800000010000e4f8, 
    __a=@0x800003fffdff0de8)
    at
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h:231
#5  0x400000000000ed6c in ~basic_string (this=0x8000000100001580)
    at
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/basic_string.h:498
#6  0x400000000000eca0 in __static_initialization_and_destruction_0 (
---Type <return> to continue, or q <return> to quit---
    __initialize_p=0, __priority=65535) at deallocate_global.cc:68
#7  0x400000000000f0a8 in global destructors keyed to _Znwm ()
    at deallocate_global.cc:73
#8  0x4000000000008bc4 in __do_global_dtors_aux ()
#9  0xc000000000032aa0 in TE_do_list#HLO_CL_#i1_0x0 ()
   from /usr/lib/pa20_64/dld.sl
#10 0xc00000000000d198 in TE_do_program_exit () from /usr/lib/pa20_64/dld.sl
#11 0x800003fffdcd762c in exit () from /lib/pa20_64/libc.2
#12 0xc00000000000b394 in UT_exit () from /usr/lib/pa20_64/dld.sl
#13 0xc00000000000b3b4 in exit () from /usr/lib/pa20_64/dld.sl
#14 0xc00000000000b478 in $START$ () from /usr/lib/pa20_64/dld.sl


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094

[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca  2009-05-17 23:20 -------
Subject: Re:  FAIL: ext/throw_allocator/deallocate_global.cc execution test

> Any news on this? I'd like to port the throw_allocator changes to 4_4-branch
> too, because the allocator is badly broken otherwise.

Sorry, I haven't had a chance to debug this.  Maybe, I will have some time
tomorrow.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094

[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test

[paolo dot carlini at oracle dot com]

------- Comment #2 from paolo dot carlini at oracle dot com  2009-05-17 15:28 -------
Any news on this? I'd like to port the throw_allocator changes to 4_4-branch
too, because the allocator is badly broken otherwise.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |paolo dot carlini at oracle
                   |                            |dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094

[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test

[paolo dot carlini at oracle dot com]

------- Comment #1 from paolo dot carlini at oracle dot com  2009-05-10 20:17 -------
This is seen only on hpux and frankly I have no idea how the recent changes to
throw_allocator (which was completely broken before) could have caused it: I
would suggest taking the testcase out of the testsuite, comment out the include
<testsuite_hooks.h> compile it -O0 -g3 (maybe better rebuilding the library too
CXXFLAGS="-O0 -g3") and try to figure out under the debugger where the last
spurious couple of delete / new comes from...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094