On 27.06.2012, at 23:07, Mikhail Tchernychev wrote: > But even you check by hand "wbuf" in the file fl_utf8.cxx you can > see that it is not freed in any place. Yes it gets re-allocated > but it is still there on exit, so it is technically memory leak, > and valgrind should report it as well.
wbuff holds the UTF16 string that is required to output UTF8 in MSWindows platforms. These conversions are quite frequent. They occur every time the FLTK needs to put text on the screen (and many more instances). It would be very inefficient to ever deallocate this buffer. The realloc call is more efficient in many cases than calling free and malloc because if a smaller block is realloc'd, the block stays the same and will simply be marked as smaller. If it is enlarged, and there is still room in that heap, it will simply be marked as larger. Both operations are much cheaper and faster than calling free(), which adds the free'd memory to the pool, and then later calling malloc() which has to search the pool for a matching block size. Additionally, realloc may even reduce memory fragmentation. Last but not least, the block will be freed by the OS when the application exits. There are a handful of buffers of this kind. Some of them are only expanding, which helps to avoid fragmentation even more. > Also, if you set break point on ~Fl_Window() in visual studio > it is newer reached in the original hello.cxx file. > > I found that > > int ret = Fl::run(); > delete window; > > causing program to crash. That actually *IS* a known bug in MSWindows and it is in the bug list, soon to be fixed. There is no need however to call "delete window", and if you don;t, you will not get that crash, without changing any of the behaviour of the program. The log that you sent shows three preferences items that remain allocated because they are used throughout the program. The first one manages the settings for the file chooser (preview or not) and could be optimized to save a few bytes. But it is no memory leak because it does not grow and get deallocated by the OS when the app exits. The two other preferences items manage the graphics plugins. Without graphics plugins, you could not draw anything to the screen or printer. They are plugins so that you can draw to screen in the exact same way that you can draw to the printer. More plugins are currently being written which allow you to have a UI hovering over an OpenGL widget, on a VNC device, or on an Android platform. These need to remain allocated as long as you want to output anything. They will be free'd as soon as the app exits. I hope that this will make things clearer. We are doing a lot of work to keep FLTK fast, light, and efficient. - Matthias > ----------------------- LOG ------------------------------ > > isual Leak Detector Version 2.2.3 installed. > WARNING: Visual Leak Detector detected memory leaks! > ---------- Block 71 at 0x02760BE0: 116 bytes ---------- > Call Stack: > g:\temp\fltk-1.3.0\src\fl_utf8.cxx (590): fltkdlld.dll!fl_fopen + 0x12 > bytes > g:\temp\fltk-1.3.0\src\fl_preferences.cxx (1160): > fltkdlld.dll!Fl_Preferences::RootNode::read + 0x14 bytes > g:\temp\fltk-1.3.0\src\fl_preferences.cxx (1101): > fltkdlld.dll!Fl_Preferences::RootNode::RootNode > g:\temp\fltk-1.3.0\src\fl_preferences.cxx (239): > fltkdlld.dll!Fl_Preferences::Fl_Preferences + 0x32 bytes > g:\temp\fltk-1.3.0\src\fl_file_chooser2.cxx (381): fltkdlld.dll!`dynamic > initializer for 'Fl_File_Chooser::prefs_'' + 0x19 bytes > f:\dd\vctools\crt_bld\self_x86\crt\src\crt0dat.c (873): > fltkdlld.dll!_initterm > f:\dd\vctools\crt_bld\self_x86\crt\src\crt0dat.c (288): > fltkdlld.dll!_cinit + 0xF bytes > f:\dd\vctools\crt_bld\self_x86\crt\src\dllcrt0.c (132): > fltkdlld.dll!_CRT_INIT + 0x19 bytes > f:\dd\vctools\crt_bld\self_x86\crt\src\dllcrt0.c (324): > fltkdlld.dll!__DllMainCRTStartup + 0x11 bytes > f:\dd\vctools\crt_bld\self_x86\crt\src\dllcrt0.c (293): > fltkdlld.dll!_DllMainCRTStartup + 0x11 bytes > 0x77A912F4 (File and line number not available): > ntdll.dll!RtlQueryInformationActivationContext + 0x1B7 bytes > 0x77A7906B (File and line number not available): > ntdll.dll!RtlEncodeSystemPointer + 0x56D bytes > 0x77A816D2 (File and line number not available): > ntdll.dll!RtlInitializeSid + 0x575 bytes > 0x77A7BF5A (File and line number not available): > ntdll.dll!RtlInitializeHandleTable + 0x5C bytes > 0x77A91450 (File and line number not available): > ntdll.dll!LdrInitializeThunk + 0x10 bytes _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
