User account creation filtered due to spam.

Bug 22482 - -fvisibility=hidden and stl -> SEGV in __gnu_cxx::__pool<true>::_M_reclaim_block
Summary: -fvisibility=hidden and stl -> SEGV in __gnu_cxx::__pool<true>::_M_reclaim_block
Status: RESOLVED DUPLICATE of bug 19664
Alias: None
Product: gcc
Classification: Unclassified
Component: libstdc++ (show other bugs)
Version: 4.0.1
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-07-14 11:41 UTC by Caolan McNamara
Modified: 2005-07-23 22:49 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
example to reproduce (710 bytes, application/x-gzip)
2005-07-14 11:42 UTC, Caolan McNamara
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Caolan McNamara 2005-07-14 11:41:52 UTC
perhaps this is user error on my side, but given the attachment, run runme.sh
and I get a stacktrace of...

#0  0x00b88dab in __gnu_cxx::__pool<true>::_M_reclaim_block () from
/usr/lib/libstdc++.so.6
#1  0x00517ff2 in __gnu_cxx::__mt_alloc<int,
__gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::deallocate
(this=0x8e571c8, __p=0x8e551f8, __n=2)
    at
/usr/lib/gcc/i386-redhat-linux/4.0.1/../../../../include/c++/4.0.1/ext/mt_allocator.h:746
#2  0x00518025 in std::_Vector_base<int, std::allocator<int> >::_M_deallocate
(this=0x8e571c8,
    __p=0x8e551f8, __n=2)
    at
/usr/lib/gcc/i386-redhat-linux/4.0.1/../../../../include/c++/4.0.1/bits/stl_vector.h:123
#3  0x0051806c in ~_Vector_base (this=0x8e571c8)
    at
/usr/lib/gcc/i386-redhat-linux/4.0.1/../../../../include/c++/4.0.1/bits/stl_vector.h:109
#4  0x0051819f in ~vector (this=0x8e571c8)
    at
/usr/lib/gcc/i386-redhat-linux/4.0.1/../../../../include/c++/4.0.1/bits/stl_vector.h:273
#5  0x005181c6 in __gnu_cxx::__mt_alloc_base<std::vector<int,
std::allocator<int> > >::destroy (
    this=0xbf9f4d2f, __p=0x8e571c8)
    at
/usr/lib/gcc/i386-redhat-linux/4.0.1/../../../../include/c++/4.0.1/ext/mt_allocator.h:614
#6  0x005181f2 in std::_Destroy<std::vector<int, std::allocator<int> >*,
std::allocator<std::vector<int, std::allocator<int> > > > (__first=0x8e571c8,
__last=0x8e571e0, __alloc=@0xbf9f4d2f)
    at
/usr/lib/gcc/i386-redhat-linux/4.0.1/../../../../include/c++/4.0.1/bits/stl_construct.h:174
#7  0x00518246 in ~vector (this=0xbf9f4d70)
    at
/usr/lib/gcc/i386-redhat-linux/4.0.1/../../../../include/c++/4.0.1/bits/stl_vector.h:273
#8  0x0051792d in testfoo () at dlgass.cxx:7
#9  0x08048531 in main ()
Comment 1 Caolan McNamara 2005-07-14 11:42:29 UTC
Created attachment 9268 [details]
example to reproduce
Comment 2 Paolo Carlini 2005-07-14 13:16:09 UTC
A couple of quick comments: in the report, you are not saying that your gcc-4.0.1
is *not* default configured (i.e., the default is the new-based allocator); also
-fvisibility is known to have *lots* of issues, irrespective of allocators (e.g.,
grep the mailing lists for some trenchant comments general considerations from
Roger Sayle).
Comment 3 Jakub Jelinek 2005-07-14 15:24:55 UTC
IMHO either we want to just force what must have default visibility to have
the default visibility (in mt_allocator.h case it is _S_get_pool), as in:
--- ext/mt_allocator.h  2005-05-20 03:36:29.000000000 +0200
+++ ext/mt_allocator.h  2005-07-14 17:17:49.000000000 +0200
@@ -413,7 +413,7 @@ namespace __gnu_cxx
         struct _M_rebind
         { typedef __common_pool_policy<_PoolTp1, _Thread1> other; };

-      static pool_type&
+      static __attribute__((visibility ("default"))) pool_type&
       _S_get_pool()
       {
        static pool_type _S_pool;
@@ -444,7 +444,7 @@ namespace __gnu_cxx
         struct _M_rebind
         { typedef __common_pool_policy<_PoolTp1, _Thread1> other; };

-      static pool_type&
+      static __attribute__((visibility ("default"))) pool_type&
       _S_get_pool()
       {
        static pool_type _S_pool;
@@ -490,7 +490,7 @@ namespace __gnu_cxx
         struct _M_rebind
         { typedef __per_type_pool_policy<_Tp1, _PoolTp1, _Thread1> other; };

-      static pool_type&
+      static __attribute__((visibility ("default"))) pool_type&
       _S_get_pool()
       {
        // Sane defaults for the _PoolTp.
@@ -536,7 +536,7 @@ namespace __gnu_cxx
         struct _M_rebind
         { typedef __per_type_pool_policy<_Tp1, _PoolTp1, _Thread1> other; };

-      static pool_type&
+      static __attribute__((visibility ("default"))) pool_type&
       _S_get_pool()
       {
        // Sane defaults for the _PoolTp.

(of course together with a libstdc++-v3/configure check for visibility
attribute and using a macro for that, __gxx_default_visibility or something
like that).
Not sure what other places in libstdc++-v3 headers rely on having the default
visibility.
Alternatively, we claim that all of libstdc++-v3 header stuff (or most of it)
needs default visibility and add
#pragma GCC visibility push(default) ... #pragma GCC visibility pop
markers around (most of) libstdc++-v3 headers, like it has been already
added for libsupc++ headers.  This wasn't possible earlier when we had the
16 GCC visibility pragmas stacking limit, but now that it is gone, we can
fix that up.  Of course the issues Roger raised need to be solved as well.
Comment 4 Andrew Pinski 2005-07-14 16:59:07 UTC
After reading comment #3, this is in fact a dup of bug 19664.

*** This bug has been marked as a duplicate of 19664 ***