Send MinGW-Notify mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.osdn.me/mailman/listinfo/mingw-notify
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of MinGW-Notify digest..."
Please do not reply to this notification; the sender address is unable to
accept incoming e-mail. If you wish to unsubscribe you can do so at
https://lists.osdn.me/mailman/listinfo/mingw-notify.
Today's Topics:
1. [mingw] #40686: std::string custom operator new/delete
function (MinGW Notification List)
2. [mingw] #40649: Memory leak at std::recursive_mutex
destruction (MinGW Notification List)
3. [mingw] #40696: MSVCRT.DLL's _pgmptr variable is
uninitialized by MinGW start-up code (MinGW Notification List)
----------------------------------------------------------------------
Message: 1
Date: Wed, 02 Sep 2020 14:10:39 +0100
From: MinGW Notification List <[email protected]>
To: OSDN Ticket System <[email protected]>
Subject: [MinGW-Notify] [mingw] #40686: std::string custom operator
new/delete function
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
#40686: std::string custom operator new/delete function
Open Date: 2020-08-30 10:32
Last Update: 2020-09-02 14:10
URL for this Ticket:
https://osdn.net//projects/mingw/ticket/40686
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=40686
---------------------------------------------------------------------
Last Changes/Comment on this Ticket:
2020-09-02 14:10 Updated by: keith
* Resolution Update from None to Works For Me
* Severity Update from 5 - Medium to 1 - Lowest
* Priority Update from 5 - Medium to 1 - Lowest
Comment:
This is an issue which really would have been better to raise on the mailing
list, where it would be visible to a broader spectrum of experienced users. My
own expertise is predominantly in FORTRAN-77 and C programming; my knowledge of
C++ is sketchy, at best. Nonetheless, I will try to answer, to the best of my
ability.
Firstly, let me make it perfectly clear: any comparison between behaviour on
Windows, and behaviour on Linux, is completely irrelevant; the two platforms
are fundamentally different, and there are many pitfalls in migrating from
either one to the other. In this case, I believe you are falling foul of one of
those pitfalls; there is no bug here, beyond a gap in your understanding.
In your test case, while you define replacements for both new and delete, I see
no explicit use of either; any use which does arise is implicit in the
instantiation, and subsequent destruction, of the std::string object, to which
you refer. Instantiation of that object, apparently, does invoke new, and
destruction thus invokes delete, but consider this: where is the implementation
of that std::string class object defined? I'll give you some time to think
about that, then I'll suggest, in follow-up comments, how the answer may
explain the behaviour you have observed.
---------------------------------------------------------------------
Ticket Status:
Reporter: marvol
Owner: (None)
Type: Issues
Status: Open
Priority: 1 - Lowest
MileStone: (None)
Component: GCC
Severity: 1 - Lowest
Resolution: Works For Me
---------------------------------------------------------------------
Ticket details:
Hello,
I am writing a custom wrapper for new/delete allocations to get an aligned
memory. I noticed that if I use std::string, operator new/delete are not called
as it is in a linux version of g++ (operators new/delete are called). With the
default optimization level, operator new/delete is not called and with
optimization levels O1, O2, O3 only operator delete is called.
Source:
1. #include <string>
2. #include <cstdio>
3. #include <cstdlib>
4.
5. void* operator new(size_t size)
6. {
7. printf("Calling new: %zu", size);
8. void* address = malloc(size);
9.
10. printf(" address: 0x%p\n", address);
11. return address;
12. }
13.
14. void* operator new[](size_t size)
15. {
16. printf("Calling new[]: %zu", size);
17. void* address = malloc(size);
18.
19. printf(" address: 0x%p\n", address);
20. return address;
21. }
22.
23. void operator delete(void* address)
24. {
25. printf("Calling delete, address: 0x%p\n", address);
26. free(address);
27. }
28.
29. void operator delete[](void* address)
30. {
31. printf("Calling delete[], address: 0x%p\n", address);
32. free(address);
33. }
34.
35. struct Obj
36. {
37. std::string m_str;
38. };
39.
40. void test()
41. {
42. Obj obj;
43. obj.m_str = "long string ......................";
44. }
45.
46. int main()
47. {
48. test();
49.
50. return 0;
51. }
Compiling with the default optimization level:
• g++ main.cpp -std=c++11 -o test.exe
Output:
• NONE
Compiling with the O2 optimization level:
• g++ main.cpp -std=c++11 -O2 -o test.exe
Output:
• Calling delete, address: 0x00542098
I am using:
• OS: Windows 7
• Mingw: 5.4.1
• Shell: cmd MINGW32_NT-6.1 MARTIN-LENOVO 1.0.18(0.48/3/2) 2012-11-21 22:34
i686 Msys
• Uname -a:
• G++: g++ (MinGW.org GCC Build-2) 9.2.0
• GCC: gcc (MinGW.org GCC Build-2) 9.2.0
• ld: GNU ld (GNU Binutils) 2.32
--
Ticket information of MinGW - Minimalist GNU for Windows project
MinGW - Minimalist GNU for Windows Project is hosted on OSDN
Project URL: https://osdn.net/projects/mingw/
OSDN: https://osdn.net
URL for this Ticket:
https://osdn.net/projects/mingw/ticket/40686
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=40686
------------------------------
Message: 2
Date: Wed, 02 Sep 2020 15:39:16 +0100
From: MinGW Notification List <[email protected]>
To: OSDN Ticket System <[email protected]>
Subject: [MinGW-Notify] [mingw] #40649: Memory leak at
std::recursive_mutex destruction
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
#40649: Memory leak at std::recursive_mutex destruction
Open Date: 2020-08-19 17:39
Last Update: 2020-09-02 15:39
URL for this Ticket:
https://osdn.net//projects/mingw/ticket/40649
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=40649
---------------------------------------------------------------------
Last Changes/Comment on this Ticket:
2020-09-02 15:39 Updated by: keith
* Status Update from Open to Closed
* Resolution Update from None to Invalid
Comment:
You clearly are not using MinGW.org products, so what makes you think we should
help with this?
Built by MinGW-W64 project)
This rogue project blatantly, and illegally, infringes our legally registered
trademark -- it is, in no way, associated with MinGW.org
---------------------------------------------------------------------
Ticket Status:
Reporter: godbille
Owner: (None)
Type: Issues
Status: Closed
Priority: 5 - Medium
MileStone: (None)
Component: GCC
Severity: 7
Resolution: Invalid
---------------------------------------------------------------------
Ticket details:
Hello,
I have a memory leak when a std::recursive_mutex object is deleted. This memory
leak happens only if the recursive_mutex has been at least locked once.
Here is a short code to reproduce the problem :
#include <mutex>
#include <thread>
int main(int argc, char *argv[]) {
while(true) {
std::recursive_mutex mu;
mu.lock();
std::this_thread::sleep_for(std::chrono::milliseconds(1));
mu.unlock();
}
return 0;
}
###############################################################################
######
Here is my GCC version : ######################################################
##########
Using built-in specs. COLLECT_GCC=C:\QtUpdate\Tools\mingw730_64\bin\gcc.exe
COLLECT_LTO_WRAPPER=C:/QtUpdate/Tools/mingw730_64/bin/../libexec/gcc/
x86_64-w64-mingw32/7.3.0/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured
with: ../../../src/gcc-7.3.0/configure --host=x86_64-w64-mingw32 --build=
x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64 --with-sysroot
=/c/mingw730/x86_64-730-posix-seh-rt_v5-rev0/mingw64 --enable-shared
--enable-static --disable-multilib --enable-languages=c,c++,fortran,lto
--enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp
--enable-libatomic --enable-lto --enable-graphite --enable-checking=release
--enable-fully-dynamic-string --enable-version-specific-runtime-libs
--enable-libstdcxx-filesystem-ts=yes --disable-libstdcxx-pch
--disable-libstdcxx-debug --enable-bootstrap --disable-rpath
--disable-win32-registry --disable-nls --disable-werror --disable-symvers
--with-gnu-as --with-gnu-ld --with-arch=nocona --with-tune=core2
--with-libiconv --with-system-zlib --with-gmp=/c/mingw730/prerequisites/
x86_64-w64-mingw32-static --with-mpfr=/c/mingw730/prerequisites/
x86_64-w64-mingw32-static --with-mpc=/c/mingw730/prerequisites/
x86_64-w64-mingw32-static --with-isl=/c/mingw730/prerequisites/
x86_64-w64-mingw32-static --with-pkgversion='x86_64-posix-seh-rev0, Built by
MinGW-W64 project' --with-bugurl=https://sourceforge.net/projects/mingw-w64
CFLAGS='-O2 -pipe -fno-ident -I/c/mingw730/x86_64-730-posix-seh-rt_v5-rev0/
mingw64/opt/include -I/c/mingw730/prerequisites/x86_64-zlib-static/include -I/c
/mingw730/prerequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe
-fno-ident -I/c/mingw730/x86_64-730-posix-seh-rt_v5-rev0/mingw64/opt/include -I
/c/mingw730/prerequisites/x86_64-zlib-static/include -I/c/mingw730/
prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS=' -I/c/mingw730/
x86_64-730-posix-seh-rt_v5-rev0/mingw64/opt/include -I/c/mingw730/prerequisites
/x86_64-zlib-static/include -I/c/mingw730/prerequisites/
x86_64-w64-mingw32-static/include' LDFLAGS='-pipe -fno-ident -L/c/mingw730/
x86_64-730-posix-seh-rt_v5-rev0/mingw64/opt/lib -L/c/mingw730/prerequisites/
x86_64-zlib-static/lib -L/c/mingw730/prerequisites/x86_64-w64-mingw32-static/
lib ' Thread model: posix gcc version 7.3.0 (x86_64-posix-seh-rev0, Built by
MinGW-W64 project)
###############################################################################
#
My binutils version : #########################################################
#######
GNU ld (GNU Binutils) 2.30
###############################################################################
#
My build environment : ########################################################
#####
MINGW64_NT-6.1 NBFR7021 2.5.0(0.295/5/3) 2016-03-31 18:47 x86_64 Msys
###############################################################################
#
--
Ticket information of MinGW - Minimalist GNU for Windows project
MinGW - Minimalist GNU for Windows Project is hosted on OSDN
Project URL: https://osdn.net/projects/mingw/
OSDN: https://osdn.net
URL for this Ticket:
https://osdn.net/projects/mingw/ticket/40649
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=40649
------------------------------
Message: 3
Date: Wed, 02 Sep 2020 16:15:59 +0100
From: MinGW Notification List <[email protected]>
To: OSDN Ticket System <[email protected]>
Subject: [MinGW-Notify] [mingw] #40696: MSVCRT.DLL's _pgmptr variable
is uninitialized by MinGW start-up code
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
#40696: MSVCRT.DLL's _pgmptr variable is uninitialized by MinGW start-up code
Open Date: 2020-08-31 23:32
Last Update: 2020-09-02 16:15
URL for this Ticket:
https://osdn.net//projects/mingw/ticket/40696
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=40696
---------------------------------------------------------------------
Last Changes/Comment on this Ticket:
2020-09-02 16:15 Updated by: keith
* Resolution Update from None to Fixed
Comment:
The attached patch resolves the anomaly. I will include it in the next mingwrt
release.
---------------------------------------------------------------------
Ticket Status:
Reporter: keith
Owner: keith
Type: Issues
Status: Open [Owner assigned]
Priority: 5 - Medium
MileStone: (None)
Component: WSL
Severity: 5 - Medium
Resolution: Fixed
---------------------------------------------------------------------
Ticket details:
According to Microsoft's GetModuleFileNameA() function documentation:
The global variable _pgmptr is automatically initialized to the full path of
the executable file,
and can be used to retrieve the full path name of an executable file.
It appears that this global variable initialization occurs, only if the
run-time start-up code calls Microsoft's __getmainargs() function, but that
exhibits defective globbing of wild-card patterns, and MinGW has not used it,
as a default start-up hook, since the release of mingwrt-3.21, in December
2014. Consequently, references to _pgmptr, in code linked against mingwrt-3.21
(and later), are likely to dereference a NULL pointer.
--
Ticket information of MinGW - Minimalist GNU for Windows project
MinGW - Minimalist GNU for Windows Project is hosted on OSDN
Project URL: https://osdn.net/projects/mingw/
OSDN: https://osdn.net
URL for this Ticket:
https://osdn.net/projects/mingw/ticket/40696
RSS feed for this Ticket:
https://osdn.net/ticket/ticket_rss.php?group_id=3917&tid=40696
------------------------------
Subject: Digest Footer
_______________________________________________
MinGW-Notify mailing list
[email protected]
https://lists.osdn.me/mailman/listinfo/mingw-notify
------------------------------
End of MinGW-Notify Digest, Vol 36, Issue 3
*******************************************
