| | [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #3151
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| Priority: | 2 - Low, e.g. a documentation error or undocumented side-effect |
|---|
| Scope: | 3 - Applies to all machines and operating systems |
|---|
| Subsystem: | Core Library |
|---|
| Summary: | memory leak in fl_utf8.cxx |
|---|
| Version: | 1.3.2 |
|---|
| Created By: | basti_simi |
|---|
| Assigned To: | matt |
|---|
| Fix Version: | None |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
No files
Trouble Report Comments:
| |
| #1 | basti_simi
02:54 Nov 11, 2014 |
| There is a memory leak fl_utf8.cxx.
#if defined(WIN32) && !defined(__CYGWIN__)
static xchar *wbuf = NULL;
static xchar *wbuf1 = NULL;
#endif
The variables wbuf and wbuf1 are alloced using realloc in fl_fopen and fl_rename but never freed. When i include Fl_FileChooser.h a static Fl_Preferences object is created which calls fl_fopen. At this point i can debug an application which just returns in main funtion. t the allocation number of the memory leak which states realloc as the source of the leak. | |
| |
| #2 | greg.ercolano
16:39 Nov 14, 2014 |
| I'd like to hear the opinion of the other devs, but it would appear
the behavior is perhaps intentional as simply a persistent buffer
that is grown/shrank on subsequent calls.
I say this because both wbuf and wbuf1 are static globals (instead
of local to each function they're used in), and span use across
multiple functions (fl_fopen() and fl_rename())
The use of realloc() ensures memory isn't grown uncontrollably
(ie. blocks of memory aren't lost) the buffer simply persists until
the next call, where it is either enlarged or shrank as needed.
That said, I can't see a good reason why these buffers couldn't be
local in each function, and malloc/free'ed in the normal way.
Devs would just have to be careful that all return() paths
first free() the buffer to prevent an /actual/ leak.
And perhaps this is the intention of the original developer;
no logic changes in return() paths can cause it to 'leak'
memory in the true sense, where memory gets lost beyond the
persistent buffer. | |
| |
| #3 | AlbrechtS
08:07 Nov 15, 2014 |
| I agree that this doesn't look like a real memory leak. Since some of these methods may be called frequently, I do also think that this can be considered optimization.
I wouldn't want to change this, particularly because there are more than only the two mentioned variables, for instance buf, mbwbuf, wbufa, and maybe more.
I suggest to close this STR w/Resolution, because there is no real memory leak, and the handling of allocation is considered optimization to avoid multiple allocation/deallocation (free). | |
| |
| #4 | matt
17:13 May 23, 2015 |
| This behavior is intentional because there is no "right" time to free this buffer. Garbage collection would be one, but that's not available in C++. The buffer is returned to the OS when the app exits. | |
[ Return to Bugs & Features ]
|
| |
