[Bug libstdc++/47762] New: FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[Bug libstdc++/47762] New: FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[danglin at gcc dot gnu.org]

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

           Summary: FAIL: ext/mt_allocator/deallocate_global_thread-1.cc
                    execution test
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: danglin@gcc.gnu.org
              Host: i686-apple-darwin9
            Target: i686-apple-darwin9
             Build: i686-apple-darwin9


Executing on host: /Users/dave/gnu/gcc/objdir/./gcc/g++ -shared-libgcc
-B/Users/
dave/gnu/gcc/objdir/./gcc -nostdinc++
-L/Users/dave/gnu/gcc/objdir/i686-apple-da
rwin9/libstdc++-v3/src
-L/Users/dave/gnu/gcc/objdir/i686-apple-darwin9/libstdc++
-v3/src/.libs -B/opt/gnu/gcc/gcc-4.6.0/i686-apple-darwin9/bin/
-B/opt/gnu/gcc/gc
c-4.6.0/i686-apple-darwin9/lib/ -isystem
/opt/gnu/gcc/gcc-4.6.0/i686-apple-darwi
n9/include -isystem /opt/gnu/gcc/gcc-4.6.0/i686-apple-darwin9/sys-include
-B/Use
rs/dave/gnu/gcc/objdir/i686-apple-darwin9/./libstdc++-v3/src/.libs -g -O2
-D_GLI
BCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -g
-O2
 -DLOCALEDIR="." -nostdinc++
-I/Users/dave/gnu/gcc/objdir/i686-apple-darwin9/lib
stdc++-v3/include/i686-apple-darwin9
-I/Users/dave/gnu/gcc/objdir/i686-apple-dar
win9/libstdc++-v3/include -I/Users/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/Us
ers/dave/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/Users/dave/gnu/gcc/gcc/lib
stdc++-v3/testsuite/util
/Users/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/ext/mt_a
llocator/deallocate_global_thread-1.cc    -include bits/stdc++.h ./libtestc++.a 
-liconv  -lm   -o ./deallocate_global_thread-1.exe    (timeout = 600)
PASS: ext/mt_allocator/deallocate_global_thread-1.cc (test for excess errors)
Setting LD_LIBRARY_PATH to
:/Users/dave/gnu/gcc/objdir/gcc:/Users/dave/gnu/gcc/o
bjdir/i686-apple-darwin9/./libstdc++-v3/../libgomp/.libs:/Users/dave/gnu/gcc/obj
dir/i686-apple-darwin9/./libstdc++-v3/src/.libs::/Users/dave/gnu/gcc/objdir/gcc:
/Users/dave/gnu/gcc/objdir/i686-apple-darwin9/./libstdc++-v3/../libgomp/.libs:/U
sers/dave/gnu/gcc/objdir/i686-apple-darwin9/./libstdc++-v3/src/.libs
FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

Also,
FAIL: ext/mt_allocator/deallocate_global_thread-3.cc execution test

dave@MACPRO:~/gnu/gcc/objdir/gcc$ ./xgcc -B./ -v
Reading specs from ./specs
COLLECT_GCC=./xgcc
COLLECT_LTO_WRAPPER=./lto-wrapper
Target: i686-apple-darwin9
Configured with: ../gcc/configure --build=i686-apple-darwin9
--host=i686-apple-darwin9 --target=i686-apple-darwin9 --with-tune=generic
--prefix=/opt/gnu/gcc/gcc-4.6.0 --with-gmp=/opt/gnu/gcc/gcc-4.6.0
--enable-debug=no --disable-nls
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-threads=posix
--enable-__cxa_atexit --enable-java-gc=boehm
Thread model: posix
gcc version 4.6.0 20110215 (experimental) [trunk revision 170201] (GCC) 

Revision 169853 was ok.

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|i686-apple-darwin9          |(i686|powerpc)-apple-darwin
                   |                            |9
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.08.08 09:25:13
                 CC|                            |bkoz at redhat dot com,
                   |                            |paolo.carlini at oracle dot
                   |                            |com
               Host|i686-apple-darwin9          |(i686|powerpc)-apple-darwin
                   |                            |9
     Ever Confirmed|0                           |1
              Build|i686-apple-darwin9          |(i686|powerpc)-apple-darwin
                   |                            |9

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-08-08 09:25:13 UTC ---
This PR appeared on ppc between revisions 147909 and 147938 (see
http://gcc.gnu.org/ml/gcc-testresults/2009-05/msg02409.html and
http://gcc.gnu.org/ml/gcc-testresults/2009-05/msg02457.html ) and is likely due
to revision 147937.

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-04-15 16:35:41 UTC ---
AFAICT the failures have disappeared on powerpc-apple-darwin9 between revisions
186224 and 186440.

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-04-15 17:08:27 UTC ---
See if, by chance, libstdc++/52604 did the "miracle". I would like that ;)

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-04-16 23:44:19 UTC ---
> See if, by chance, libstdc++/52604 did the "miracle". I would like that ;)

Yep! At revision 186396, I get for
RUNTESTFLAGS="conformance.exp=deallocate_global_thread* ..."

Running target unix/-m32
FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test
FAIL: ext/mt_allocator/deallocate_global_thread-3.cc execution test

        === libstdc++ Summary for unix/-m32 ===

# of expected passes        2
# of unexpected failures    2

Running target unix/-m64
FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test
FAIL: ext/mt_allocator/deallocate_global_thread-3.cc execution test

        === libstdc++ Summary for unix/-m64 ===

# of expected passes        2
# of unexpected failures    2

        === libstdc++ Summary ===

# of expected passes        4
# of unexpected failures    4

With the change in revision 186414, I get

        === libstdc++ Summary for unix/-m32 ===

# of expected passes        4

        === libstdc++ Summary for unix/-m64 ===

# of expected passes        4

        === libstdc++ Summary ===

# of expected passes        8

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[paolo.carlini at oracle dot com]

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

--- Comment #5 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-04-16 23:51:45 UTC ---
Oh good. The I suppose that in the 4_7-branch the problem still exists: care to
check if the same patchlet works there too?

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |iains at gcc dot gnu.org

--- Comment #6 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-04-17 11:00:09 UTC ---
> Oh good. The I suppose that in the 4_7-branch the problem still exists: 

I did not check recently, but I guess so.

> care to check if the same patchlet works there too?

I'll be away the next two weeks with limited access to the net. When is 7.4.1
supposed to be released?

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[chrbr at gcc dot gnu.org]

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

chrbr at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |chrbr at gcc dot gnu.org

--- Comment #7 from chrbr at gcc dot gnu.org 2012-04-18 07:10:45 UTC ---
Extended the testsuite to force threads, so that __gthread_active_p path is on,
we still get segfaults on deallocate_global_thread-1.cc 

Backtrace is in __gthread_key_delete(_M_key), _M_key is 0 at this point.

    ~__freelist()
    {
      if (_M_thread_freelist_array)
    {
      __gthread_key_delete(_M_key);
      ::operator delete(static_cast<void*>(_M_thread_freelist_array));
      _M_thread_freelist = 0;
    }
    }

since the _M_thread_freelist setting to 0 is done afterward, I'm afraid this is
still fragile and mt_deallocate still have pending issues.

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[paolo.carlini at oracle dot com]

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

--- Comment #8 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-04-18 09:34:16 UTC ---
Ok, let's not touch the branch for the time being. If you can figure out other
fixes on top of the first one, please let us know (preferably, on the mailing
list).

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[chrbr at gcc dot gnu.org]

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

--- Comment #9 from chrbr at gcc dot gnu.org 2012-04-18 10:23:57 UTC ---
Created attachment 27181
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27181
test ?

For the record, here is the modified version of the test I'm playing with. 

compiled with

g++ deallocate_global_thread-1.cc -static -pthread -O0 -g 

I'll try to figure out what happens if the failure is related or not to this
bug.

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jwakely.gcc at gmail dot
                   |                            |com

--- Comment #10 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-04-18 11:54:27 UTC ---
You mean that with -static it doesn't even compile?!? It seems weird indeed,
let's add Jon in CC, maybe there is a simple explanation for that.

Otherwise, without -static the testcase seems pretty benign...

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[paolo.carlini at oracle dot com]

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

--- Comment #11 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-04-18 12:01:27 UTC ---
Of course I meant it doesn't *link*. I guess I have never noticed this error
before:

/usr/bin/ld: cannot find -lm
/usr/bin/ld: cannot find -lpthread
/usr/bin/ld: cannot find -lc

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[iains at gcc dot gnu.org]

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

--- Comment #12 from Iain Sandoe <iains at gcc dot gnu.org> 2012-04-18 12:08:55 UTC ---
(In reply to comment #11)
> Of course I meant it doesn't *link*. I guess I have never noticed this error
> before:
> 
> /usr/bin/ld: cannot find -lm
> /usr/bin/ld: cannot find -lpthread
> /usr/bin/ld: cannot find -lc

darwin does not support -static for user space code.
-static-libstdc++ should work.

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[paolo.carlini at oracle dot com]

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

--- Comment #14 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-04-18 12:19:04 UTC ---
But anyway -static-libstdc++ works on Linux too to avoid the link-time problem.
Still (on x86_64-linux) the testcase runs Ok for me.

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

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

--- Comment #13 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-04-18 12:15:56 UTC ---
I'm on Linux (I'm always on Linux by default)

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[iains at gcc dot gnu.org]

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

--- Comment #15 from Iain Sandoe <iains at gcc dot gnu.org> 2012-04-18 12:31:06 UTC ---
(In reply to comment #14)
> But anyway -static-libstdc++ works on Linux too to avoid the link-time problem.
> Still (on x86_64-linux) the testcase runs Ok for me.

OK. 
Just for the record - in case anyone is trying permutations;

libc, libm,  libpthread etc. are combined into libSystem.dylib on Darwin -
which is always required to be a dynamic link for User space code.

The compiler target libraries (less the NeXT objc one) can be linked statically
- including libgomp (since pthreads are always available via libSystem),

so static-lib{stdcc++, fortran, gcc} will work (barring other errors).

Note, however, that using -static-libgcc will *only* work so long as you don't
want to use any library [other than libSystem] or framework from /usr/lib or
/System or /Library that uses the unwinder.

Also, there is another (so far unhandled) bug with unwind generated by gcc >
4.5 - if you want to test code 'by hand' you should do
DYLD_LIBRARY_PATH=/path/to/gcc/build/dir  executable.

Sorry, it's on my TODO - but only applies to Darwin 9 (Darwin >= 10 is OK, so
far).

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[chrbr at gcc dot gnu.org]

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

--- Comment #16 from chrbr at gcc dot gnu.org 2012-04-18 12:37:47 UTC ---
(In reply to comment #14)
> But anyway -static-libstdc++ works on Linux too to avoid the link-time problem.
> Still (on x86_64-linux) the testcase runs Ok for me.

Interesting, it segfaults for me on a RH-5.4while calling __gthread_key_delete.

I thought that gthread_key_delete would be mapped to pthread_key_delete from
the gthr-posix but it is not, because_GLIBCXX_GTHREAD_USE_WEAK is defined.
which seems to be the problem.

(I configured with --enable-threads=posix with the glibc). But I was using the
system's glibc. I'll try to recompile my own.

by the way, (not the bug), I'm wondering if there is another way than
using pthread_key_create to hold the thread's freelist ? like using TLS in the
mt_allocator ?

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[redi at gcc dot gnu.org]

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

--- Comment #17 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-04-18 12:43:00 UTC ---
does it help if you link to libpthread using --whole-archive ?

g++ deallocate_global_thread-1.cc -static  -Wl,--whole-archive -lpthread
-Wl,--no-whole-archive -lrt

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[redi at gcc dot gnu.org]

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

--- Comment #18 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-04-18 12:57:15 UTC ---
(In reply to comment #16)
> by the way, (not the bug), I'm wondering if there is another way than
> using pthread_key_create to hold the thread's freelist ? like using TLS in the
> mt_allocator ?

Probably, but TLS isn't supported everywhere so it might need to be a separate
tls_allocator that's only conditionally available.

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[chrbr at gcc dot gnu.org]

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

--- Comment #20 from chrbr at gcc dot gnu.org 2012-04-18 13:32:31 UTC ---
(In reply to comment #17)
> does it help if you link to libpthread using --whole-archive ?
> 
> g++ deallocate_global_thread-1.cc -static  -Wl,--whole-archive -lpthread
> -Wl,--no-whole-archive -lrt

yes it works ! without whole-archive:

nm a.out | grep pthread_key_delete
w pthread_key_delete

with whole-archive:
00000000004064a0 T pthread_key_delete

now it worked for Paolo without it :-(

So final conclusion is that there seems to have no problem with
deallocate_global_thread-1.cc 

thanks !

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[redi at gcc dot gnu.org]

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

--- Comment #21 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-04-18 14:02:37 UTC ---
(In reply to comment #20)
> now it worked for Paolo without it :-(

Some distros rebuild libpthread.a to make it work automatically.

http://lists.opensuse.org/opensuse-bugs/2010-07/msg02319.html

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[paolo.carlini at oracle dot com]

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

--- Comment #19 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-04-18 13:10:59 UTC ---
At the moment I'm using an x86_64-linux machine using glibc 2.14.1, not a RH,
really no problem with this specific testcase, no Seg fault, no valgrind
errors, with 4.7.1 too.

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[paolo.carlini at oracle dot com]

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

--- Comment #22 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-04-18 14:14:37 UTC ---
To be clear: for some reason, on my Linux machine, I badly need
-static-libstdc++, what suggested by Jon in Comment #17 doesn't change much. If
code compiles and links then runs fine. So, assuming we are able to handle the
link-time issues ;) things seem in pretty good shape.

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[paolo.carlini at oracle dot com]

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

--- Comment #23 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-04-18 14:24:47 UTC ---
Ah, thanks Jon, that may indeed explain it!

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[dominiq at lps dot ens.fr]

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

--- Comment #24 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> AFAICT the failures have disappeared on powerpc-apple-darwin9 between 
> revisions 186224 and 186440.

Unfortunately they have reappeared between revisions 197010 (OK) and 197531
(FAIL).

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[redi at gcc dot gnu.org]

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

--- Comment #25 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I think this test should have:

{ dg-additional-options "-pthread" { target pthread } }