[Bug debug/47308] Dwarf Error: Cannot find signatured DIE referenced from DIE at 0x2581 [in module D:\main64.exe]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47308 --- Comment #19 from Zouzou internet at 123gen dot com 2013-03-24 20:56:40 UTC --- Hi, This appears to have been fixed. I can no longer reproduce it with GCC 4.8 and GDB 7.5.
[Bug libstdc++/53578] include/ext/concurrence.h relies on ill-formed narrowing conversions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53578 --- Comment #12 from Zouzou internet at 123gen dot com 2012-06-29 14:16:16 UTC --- applying the changes in rev 188646 to a MinGW with GCC 4.7.0 works fine and doesn't reproduce the problem detailed in bug 46455.
[Bug debug/47308] Dwarf Error: Cannot find signatured DIE referenced from DIE at 0x2581 [in module D:\main64.exe]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47308 Zouzou internet at 123gen dot com changed: What|Removed |Added CC||internet at 123gen dot com --- Comment #18 from Zouzou internet at 123gen dot com 2012-06-16 12:55:20 UTC --- Hi, Using GCC 4.7 GDB 7.4 from a regular MinGW install (mingw-get install gcc gdb), I can reproduce this. Just adding -g-dwarf4 is enough to create the problem. It seems GDB 7.4 chokes on the DWARF 4 information. The test case is then very simple: just a int* x = 0; *x = 2; or any other simple crash. When the program crashes, GDB displays that error instead of interrupting the program and doesn't allow getting a backtrace. I would love to see this fixed in order to use DWARF 4 (its duplicated type DIE elimination especially). Here are my GCC GDB configs; feel free to ask for more information: gcc -v: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.7.0/lto-wrapper.exe Target: mingw32 Configured with: ../gcc-4.7.0/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --disable-build-poststage1-with-cxx --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw Thread model: win32 gcc version 4.7.0 (GCC) gdb -v: GNU gdb (GDB) 7.4 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i686-pc-mingw32. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/.
[Bug c++/47169] New: cannot deduce base class functions from a lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47169 Summary: cannot deduce base class functions from a lambda Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: inter...@123gen.com Created attachment 22899 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22899 test case hi, when capturing this in a lambda, i can correctly call functions of the captured class from inside the lambda; but i can't call functions of base classes of the captured class from inside the lambda. i am attaching a test case to show the problem. lambda2 calls a function of Derived (the captured class) and that works fine. however, lambda1 calls a function of a base class of Derived, which GCC can't seem to resolve: test.cpp: In lambda function: test.cpp:13:6: error: cannot call member function 'void Base::f()' without object by explicitly adding this- before the call to f(), lambda1 then compiles fine. i am testing this with GCC 4.5.2 on Win. this is similar to bug #46047, except that the test case in that bug report works for me. this case is therefore slightly different. note that i don't know of the validity of calling a base class function without adding this-, but i'd think it should be resolved by the compiler just like any base member function call made outside of a lambda. note also that the Microsoft compiler swallows this test case just fine. Zouzou
[Bug libstdc++/46455] resource leaks due to missing destructors for mutexes and condvars
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46455 --- Comment #32 from Zouzou internet at 123gen dot com 2010-11-17 22:38:53 UTC --- (In reply to comment #31) Created attachment 22436 [details] add destructors in ext/concurrence.h a simpler version - could you test this on mingw? thanks great, compiles and fixes the resource leaks.
[Bug libstdc++/46455] resource leaks due to missing destructors for mutexes and condvars
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46455 --- Comment #17 from Zouzou internet at 123gen dot com 2010-11-16 08:37:02 UTC --- (In reply to comment #16) Created attachment 22413 [details] add destructors in ext/concurrence.h could you try applying this patch to ext/concurrence.h and let me know if it works on Windows? I'm testing on Linux, FreeBSD and OpenBSD but they all use the pthreads model and I don't have a Windows system to test on. hi, the patch first produced a trivial compiler error: In file included from c:\mingw\bin\../lib/gcc/mingw32/4.5.0/include/c++/memory:7 8:0, from test.cpp:15: c:\mingw\bin\../lib/gcc/mingw32/4.5.0/include/c++/ext/concurrence.h: In destruct or '__gnu_cxx::__recursive_mutex::~__recursive_mutex()': c:\mingw\bin\../lib/gcc/mingw32/4.5.0/include/c++/ext/concurrence.h:224:35: erro r: cannot convert '__gthread_recursive_mutex_t*' to '__gthread_mutex_t*' for arg ument '1' to 'void __gthread_mutex_destroy(__gthread_mutex_t*)' i worked around it by making the pointer cast explicit in the __recursive_mutex destructor: __gthread_mutex_destroy(reinterpret_cast__gthread_mutex_t*(_M_mutex)); it then compiles fine and correctly fixes the issue at hand.
[Bug libstdc++/46455] resource leaks due to missing destructors for mutexes and condvars
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46455 --- Comment #24 from Zouzou internet at 123gen dot com 2010-11-16 22:29:35 UTC --- (In reply to comment #23) Created attachment 22424 [details] add destructors in ext/concurrence.h here's another patch, this one uses SFINAE to select an appropriate overload based on the type of __gthread_recursive_mutex_t and if necessary extracts a __gthread_mutex_t from it to pass to __gthread_mutex_destroy this will be wrong if a recursive mutex type needs more cleanup than just destroying its non-recursive mutex, though I don't think that's a problem for any current systems supported by gthreads. could be improved upon by disabling the third _S_destroy overload when recursive_mutex_type is not the same as mutex_type, but it's ugly enough already. Zouzou, could you test this on mingw? thanks same compiler error as for the previous patch: In file included from c:\mingw\bin\../lib/gcc/mingw32/4.5.0/include/c++/memory:78:0, from test.cpp:15: c:\mingw\bin\../lib/gcc/mingw32/4.5.0/include/c++/ext/concurrence.h: In static member function 'static int __gnu_cxx::__recursive_mutex::_S_destroy(_Rm*, ...) [with _Rm = __gthread_recursive_mutex_t]': c:\mingw\bin\../lib/gcc/mingw32/4.5.0/include/c++/ext/concurrence.h:224:22: instantiated from here c:\mingw\bin\../lib/gcc/mingw32/4.5.0/include/c++/ext/concurrence.h:284:44: error: cannot convert '__gthread_recursive_mutex_t*' to '__gthread_mutex_t*' for argument '1' to 'void __gthread_mutex_destroy(__gthread_mutex_t*)' (my line numbers are off by 2 compared to your patches.) apparently the 1st overload doesn't match so it falls back to the 3rd one.
[Bug libstdc++/46455] resource leaks due to missing destructors for mutexes and condvars
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46455 --- Comment #29 from Zouzou internet at 123gen dot com 2010-11-17 07:38:39 UTC --- (In reply to comment #28) Created attachment 22427 [details] add destructors in ext/concurrence.h almost the same as the last patch but the destructor calls: _S_destroy__gthread_recursive_mutex_t(_M_mutex, 0); different error this time: In file included from c:\mingw\bin\../lib/gcc/mingw32/4.5.0/include/c++/memory:78:0, from test.cpp:15: c:\mingw\bin\../lib/gcc/mingw32/4.5.0/include/c++/ext/concurrence.h: In static member function 'static int __gnu_cxx::__recursive_mutex::_S_destroy(_Rm*, typename __gnu_cxx::__recursive_mutex::_Detect_win32_Rm, ( _Rm:: sema)::type*) [with _Rm = __gthread_recursive_mutex_t, typename __gnu_cxx::__recursive_mutex::_Detect_win32_Rm, ( _Rm:: sema)::type = __gthread_mutex_t]': c:\mingw\bin\../lib/gcc/mingw32/4.5.0/include/c++/ext/concurrence.h:224:54: instantiated from here c:\mingw\bin\../lib/gcc/mingw32/4.5.0/include/c++/ext/concurrence.h:267:46: error: void value not ignored as it ought to be because __gthread_mutex_destroy returns void. after changing the return types of the _S_destroy functions to void and removing the return specifiers, the test case compiles and runs fine without any leak.
[Bug libstdc++/46455] shared_ptr consuming too many semaphores on Windows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46455 --- Comment #8 from Zouzou internet at 123gen dot com 2010-11-15 13:38:39 UTC --- (In reply to comment #5) (In reply to comment #2) What's the value of __gnu_cxx::__default_lock_policy on Mingw? Is it the same for GCC 4.4 and 4.5? Between 4.4 and 4.5 there are some changes to the ghtr-win32.h file which provides the gthreads abstraction layer, but there are no significant changes to shared_ptr. So for the moment I think it's either a change in the atomic operations supported by mingw or a change in the threading layer, not shared_ptr Well, I've tested it with mingw-w64 toolchains (64-bit and 32-bit) and I couldn't reproduce this issue. Nevertheless it could be related here to some modifications done by mingw.org on their toolchain. So threading model is here something to look for. Kai i have just tried with the mingw64 currently in Cygwin (GCC 4.5.1) and it indeed doesn't exhibit this problem. i then tried to get the value of __gnu_cxx::__default_lock_policy on mingw64 and there, it is 2 (whereas it is 1 on vanilla mingw).
[Bug libstdc++/46455] shared_ptr consuming too many semaphores on Windows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46455
--- Comment #9 from Zouzou internet at 123gen dot com 2010-11-15 13:46:33 UTC
---
(In reply to comment #7)
Could you try this, which is a simplified version of the shared_ptr
refcounting
code and should have the same behaviour:
#include ext/atomicity.h
#include ext/concurrence.h
#include assert.h
static int count0 = 0;
struct X
{
X() : count1(1), count2(1) { ++count0; }
~X() { assert( count1==0 ); assert( count2==0 ); --count0; }
void release()
{
if (__gnu_cxx::__exchange_and_add_dispatch(count1, -1) == 1)
{
if (__gnu_cxx::__exchange_and_add_dispatch(count2, -1) == 1)
delete this;
}
}
__gnu_cxx::__mutex m;
_Atomic_word count1;
_Atomic_word count2;
};
int main()
{
for (int i=0; i100; ++i)
{
X* x = new X;
x-release();
}
assert( count0 == 0 );
}
[i added a Sleep(100) call after x-release(); for easier diagnostics.]
this code produces the same behavior as my test case (increasing number of
semaphores, over 100 after 10 seconds) on both vanilla MinGW and mingw64.
to summarize: my test case (standard shared_ptr creation) worked fine on
mingw64 (which has a __gnu_cxx::__default_lock_policy = 2) but bugged on
vanilla MinGW (which has a __gnu_cxx::__default_lock_policy = 1); but this one
produces the bug in both cases.
[Bug libstdc++/46455] shared_ptr consuming too many semaphores on Windows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46455
--- Comment #11 from Zouzou internet at 123gen dot com 2010-11-15 16:30:21
UTC ---
(In reply to comment #10)
That's because my simpler test ignores the default_lock_policy, it always uses
a mutex, which is what shared_ptr does when __default_lock_policy=1
I've just looked at __gnu_cxx::__mutex and it doesn't have a destructor, so
the
problem is probably just that we leak the mutex. This should show the same
bug:
#include ext/concurrence.h
int main()
{
for (int i=0; i100; ++i)
__gnu_cxx::__mutex m;
}
Could you test that?
We should add a destructor to __mutex, which calls __gthread_mutex_destroy.
N.B. this could cause a problem on FreeBSD
http://www.freebsd.org/cgi/query-pr.cgi?pr=150889
so we might want to only call __gthread_mutex_destroy when we have used
__GTHREAD_MUTEX_INIT_FUNCTION
this does reproduce the issue on both vanilla MinGW and MinGW64.
[Bug libstdc++/46455] New: shared_ptr consuming too many semaphores on Windows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46455
Summary: shared_ptr consuming too many semaphores on Windows
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: inter...@123gen.com
Created attachment 22383
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22383
test case
hello,
i have just hit a bug in the implementation of shared_ptr in GCC 4.5 on
Windows. the bug wasn't present in GCC 4.4.
the bug is also specific to libstdc++: when using boost or MSVC, there is no
problem.
basically, any creation of a shared_ptr increases the amount of semaphores used
by the process. this can be viewed by running the Task Manager and looking into
the Handles column. the semaphores are never released and the count therefore
keeps increasing without rest.
the following simple prog shows it:
int main() {
int n=0;
while (++n 100) {
//shared_ptrstring x = make_sharedstring(test);
shared_ptrstring x(new string(test));
Sleep(100);
}
return 0;
}
(using either make_shared or the constructor doesn't make a difference.)
when running it, you will notice a steady increase of the amount of handles,
reaching more than 100 handles after 10 seconds.
compile the same prog with MSVC or GCC 4.4 and notice that the amount of
handles doesn't grow.
of course, for this simple example, it is inoffensive, but programs that make a
more important use of shared_ptr can quickly run out of available handles and
crash in unexpected ways.
for reference, the whole discussion is on
https://bugs.launchpad.net/dcplusplus/+bug/654040.
[Bug libstdc++/46455] shared_ptr consuming too many semaphores on Windows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46455 --- Comment #3 from Zouzou internet at 123gen dot com 2010-11-12 20:56:14 UTC --- (In reply to comment #2) What's the value of __gnu_cxx::__default_lock_policy on Mingw? Is it the same for GCC 4.4 and 4.5? it is 1 on both. (i got it using std::cout __gnu_cxx::__default_lock_policy; hope that's correct.)
