CODEWITHSUNDEEP
memory-leaksvalgrindada
user571138
user571138

Reputation:

Memory leak in Ada.Strings.Unbounded ?

I have a curious memory leak, it seems that the library function to_unbounded_string is leaking!

Code snippets: 

procedure Parse (Str    : in     String;

... do stuff... 

declare
   New_Element : constant Ada.Strings.Unbounded.Unbounded_String :=
     Ada.Strings.Unbounded.To_Unbounded_String (Str); -- this leaks
begin

valgrind output: 

==6009== 10,276 bytes in 1 blocks are possibly lost in loss record 153 of 153
==6009==    at 0x4025BD3: malloc (vg_replace_malloc.c:236)
==6009==    by 0x42703B8: __gnat_malloc (in /usr/lib/libgnat-4.4.so.1)
==6009==    by 0x4269480: system__secondary_stack__ss_allocate (in /usr/lib/libgnat-4.4.so.1)
==6009==    by 0x414929B: ada__strings__unbounded__to_unbounded_string (in /usr/lib/libgnat-4.4.so.1)
==6009==    by 0x80F8AD4: syntax__parser__dash_parser__parseXn (token_parser_g.adb:35)

Where token_parser_g.adb:35 is listed above as the "-- this leaks" line.

Other info: Gnatmake version 4.4.5. gcc version 4.4 valgrind version valgrind-3.6.0.SVN-Debian, valgrind options -v --leak-check=full --read-var-info=yes --show-reachable=no

Any help or insights appreciated,

NWS.

Upvotes: 2

Views: 1334

Answers (3)

trashgod
trashgod

Reputation: 205785

Are bound[ed] strings scoped?

Expanding on @T.E.D.'s comments, Ada.Strings.Bounded "objects should not be implemented by implicit pointers and dynamic allocation." Instead, the maximum size is fixed when the generic in instantiated. As an implmentation detail, GNAT uses a discriminant to specify the maximum size of the string and a record to store the current size & contents.

In contrast, Ada.Strings.Unbounded requires that "No storage associated with an Unbounded_String object shall be lost upon assignment or scope exit." As an implmentation detail, GNAT uses a buffered implementation derived from Ada.Finalization.Controlled. As a result, the memory used by an Unbounded_String may appear to be a leak until the object is finalized, as for example when the code returns to an enclosing scope.

Upvotes: 1

T.E.D.
T.E.D.

Reputation: 44804

Was trying to keep this to comments, but what I was saying got too long and started to need formatting.

In Ada string objects are generally assumed to be perfectly-sized. The language provies functions to return the size and bounds of any string. Because of this, string handling in Ada is very different than C, and in fact more resembles how you'd do it in a functional language like Lisp.

But the basic principle is that, except in some very unusual situations, if you find yourself using Ada.Strings.Unbounded, you are going about things the wrong way.

The one case where you really can't get around using a variable-length string (or perhaps a buffer with a separate valid_length variable), is when reading strings as input from some external source. As you say, your parsing example is such a situation.

However, even here you should only have that situation on the initial buffer. Your call to your Parse routine should look something like this:

Ada.Text_IO.Get_Line (Buffer, Buffer_Len);
Parse (Buffer(Buffer'first..Buffer'first + Buffer_Len - 1));

Now inside the Parse routine you have a perfectly-sized constant Ada string to work with. If for some reason you need to pull out a subslice, you would do the following:

... --// Code to find start and end indices of my subslice
New_Element : constant String := Str(Element_Start...Element_End);

If you don't actually need to make a copy of that data for some reason though, you are better off just finding Element_Start and Element_End and working with a slice of the original string buffer. Eg:

if Str(Element_Start..Element_End) = "MyToken" then

I know this doesn't answer your question about Ada.Strings.Unbounded possibly leaking. But even if it doesn't leak, that code is relatively wasteful of machine resources (CPU and memory), and probably shouldn't be used for string manipulation unless you really need it.

Upvotes: 1

user405725
user405725

Reputation:

Valgrind clearly says that there is possibly a memory leak. It doesn't necessarily mean there is one. For example, if first call to that function allocates a pool of memory that is re-used during the life time of the program but is never freed, Valgrind will report it as a possible memory leak, even though it is not, as this is a common practice and memory will be returned to OS upon process termination.

Now, if you think that there is a memory leak for real, call this function in a loop, and see it memory continues to grow. If it does - file a bug report or even better, try to find and fix the leak and send a patch along with a bug report.

Hope it helps.

Upvotes: 4

Related Questions