CB2007 ofstream: mem/critical section leak?..

contains all delphi packages mentioned below

CB2007 ofstream: mem/critical section leak?..

Postby BugDigger » Wed Jun 19, 2013 8:08 am

HI!

Last version of madExcept on CB2007, XP/32.

New VCL form app, button:

#include<fstream>
void __fastcall TForm1::Button1Click(TObject *Sender)
{
std::ofstream f("Test.txt");
}

I see strange leak reports on program exit.

-----------------------------------------------------------------------
Linker->Dynamic RTL off, Packages->Runtime packages off. (I mainly use this configuration)

allocation number: 1908
program up time: 1.88 s
type: InitializeCriticalSection
address: $4da8c4
access rights: read/write

main thread ($fa4):
671d0820 madExcept32.dll madExceptDbg 4159 InitializeCriticalSectionCallback
004c0a6e Project3.exe __create_lock
004c12eb Project3.exe __lock_stream
0049c273 Project3.exe _setvbuf
004c1759 Project3.exe std _Init_atexit.Destroy
004c17cb Project3.exe _fopen
0049c987 Project3.exe std _Fiopen
00404a1e Project3.exe fstream 139 std.basic_filebuf
0040477d Project3.exe fstream 765 std.basic_ofstream
004046a1 Project3.exe unit1.cpp 19 TForm1.Button1Click

allocation number: 1918
program up time: 1.88 s
type: InitializeCriticalSection
address: $4da8dc
access rights: read/write

main thread ($fa4):
671d0820 madExcept32.dll madExceptDbg 4159 InitializeCriticalSectionCallback
004c0a6e Project3.exe __create_lock
004c4717 Project3.exe __lock_handle
004c148d Project3.exe ___close
0049c59e Project3.exe _fclose
00405062 Project3.exe fstream 180 std.basic_filebuf
00404b15 Project3.exe fstream 107 std.basic_filebuf
004047f4 Project3.exe fstream 813 std.basic_ofstream
004046c9 Project3.exe unit1.cpp 20 TForm1.Button1Click
-----------------------------------------------------------------------
Linker->Dynamic RTL on, Packages->Runtime packages on. (For testing)

allocation number: 1200
program up time: 1.98 s
type: GetMem
address: $502eff0
size: 16
access rights: read/write

main thread ($efc):
671ca8b9 madExcept32.dll madExceptDbg 1453 GetMemCallback
32862333 CC3280MT.DLL _malloc
3282324c CC3280MT.DLL $bnew
00409007 Project3.exe xlocale 1266 std.ctype
00408b71 Project3.exe xlocale 323 std.use_facet
004083c4 Project3.exe ios 117 std.basic_ios
00407ef6 Project3.exe ios 128 std.basic_ios
00407c04 Project3.exe ostream 51 std.basic_ostream
004079e6 Project3.exe fstream 763 std.basic_ofstream
0040795d Project3.exe unit1.cpp 19 TForm1.Button1Click

allocation number: 1204
program up time: 1.98 s
type: GetMem
address: $5026e00
size: 512
access rights: read/write

main thread ($efc):
671ca8b9 madExcept32.dll madExceptDbg 1453 GetMemCallback
32862333 CC3280MT.DLL _malloc
32861c7d CC3280MT.DLL _calloc
3285a0c6 CC3280MT.DLL __Getctyptab
00409950 Project3.exe xlocinfo 75 std._Locinfo._Getctype
004097f4 Project3.exe xlocale 1287 std.ctype
00409434 Project3.exe xlocale 1259 std.ctype
00409058 Project3.exe xlocale 1266 std.ctype
00408b71 Project3.exe xlocale 323 std.use_facet
004083c4 Project3.exe ios 117 std.basic_ios
00407ef6 Project3.exe ios 128 std.basic_ios
00407c04 Project3.exe ostream 51 std.basic_ostream
004079e6 Project3.exe fstream 763 std.basic_ofstream
0040795d Project3.exe unit1.cpp 19 TForm1.Button1Click

allocation number: 1207
program up time: 1.98 s
type: GetMem
address: $5020ff8
size: 8
access rights: read/write

main thread ($efc):
671ca8b9 madExcept32.dll madExceptDbg 1453 GetMemCallback
32862333 CC3280MT.DLL _malloc
3282324c CC3280MT.DLL $bnew
328213e6 CC3280MT.DLL std locale.facet._Register
00408be3 Project3.exe xlocale 339 std.use_facet
004083c4 Project3.exe ios 117 std.basic_ios
00407ef6 Project3.exe ios 128 std.basic_ios
00407c04 Project3.exe ostream 51 std.basic_ostream
004079e6 Project3.exe fstream 763 std.basic_ofstream
0040795d Project3.exe unit1.cpp 19 TForm1.Button1Click

allocation number: 1211
program up time: 1.98 s
type: GetMem
address: $5018ff8
size: 8
access rights: read/write

main thread ($efc):
671ca8b9 madExcept32.dll madExceptDbg 1453 GetMemCallback
32862333 CC3280MT.DLL _malloc
3282324c CC3280MT.DLL $bnew
00408677 Project3.exe xlocale 586 std.codecvt
00408195 Project3.exe xlocale 323 std.use_facet
00407d23 Project3.exe fstream 143 std.basic_filebuf
00407a39 Project3.exe fstream 765 std.basic_ofstream
0040795d Project3.exe unit1.cpp 19 TForm1.Button1Click

allocation number: 1217
program up time: 1.98 s
type: GetMem
address: $544cff8
size: 8
access rights: read/write

main thread ($efc):
671ca8b9 madExcept32.dll madExceptDbg 1453 GetMemCallback
32862333 CC3280MT.DLL _malloc
3282324c CC3280MT.DLL $bnew
328213e6 CC3280MT.DLL std locale.facet._Register
00408207 Project3.exe xlocale 339 std.use_facet
00407d23 Project3.exe fstream 143 std.basic_filebuf
00407a39 Project3.exe fstream 765 std.basic_ofstream
0040795d Project3.exe unit1.cpp 19 TForm1.Button1Click
-----------------------------------------------------------------------

What do you think about it?
Is this real leaks (all kinds of quirks are possible in borland as we know) or a problem in leak detector?
BugDigger
 
Posts: 29
Joined: Sun Jun 17, 2012 10:10 am

Re: CB2007 ofstream: mem/critical section leak?..

Postby madshi » Wed Jun 19, 2013 8:23 am

I can't really say, just from this information. The only way to find out for sure would be to analyze the Borland source code to find out if the leaks can occur like reported.

In any case, since the leaks don't seem to be caused by your own code, you'd probably be safe ignoring them. Unless they pile up more and more, the longer your process runs? Every leak that only occurs once and then never again (regardless of how long your process runs) isn't really a problem. Problematic are leaks which pile up over time...
madshi
Site Admin
 
Posts: 9380
Joined: Sun Mar 21, 2004 5:25 pm

Re: CB2007 ofstream: mem/critical section leak?..

Postby BugDigger » Wed Jun 19, 2013 12:02 pm

> I can't really say, just from this information. The only way to find out for sure would be to analyze
> the Borland source code to find out if the leaks can occur like reported.

Yes, you are right in general. But strange thing here is different leaks: critical section in static version and pure memory leak in dynamic one.
If you have interest (i.e. if you suspect that mad tools have some problem with leak detection here) I can provide compiled exes and other needed information.

> Problematic are leaks which pile up over time.

If I press the button twice I see the same leak report (no doubled leaks), so the problem is not critical. It also can be some intentional leaks (as known others In RTL/VCL)...
BugDigger
 
Posts: 29
Joined: Sun Jun 17, 2012 10:10 am

Re: CB2007 ofstream: mem/critical section leak?..

Postby madshi » Wed Jun 19, 2013 1:32 pm

Leak reporting in BCB is a bit more complicated than in Delphi. E.g. in BCB you can also have the RTL dynamic or static, in addition to using runtime packages or not. I'm not sure exactly why the leaks are different in those 2 different situations. But analyzing that would cost a lot of time, so I'm not really eager to do that, unless there's a clear indication that there's a bug in madExcept somewhere...
madshi
Site Admin
 
Posts: 9380
Joined: Sun Mar 21, 2004 5:25 pm

Re: CB2007 ofstream: mem/critical section leak?..

Postby BugDigger » Thu Jun 20, 2013 7:00 am

> I'm not sure exactly why the leaks are different in those 2 different situations.

Probably the most simple way to reproduce it on your side is tracing of code compiled with your CB version (XE3/4 ?).

> But analyzing that would cost a lot of time

OK, I understand it. :-)
Thank you for input and your excellent tools!
Best regards.
BugDigger
 
Posts: 29
Joined: Sun Jun 17, 2012 10:10 am


Return to madCollection

Who is online

Users browsing this forum: No registered users and 1 guest