Menu

#60 string bug in operator=

closed-works-for-me
7
2006-09-12
2006-08-16
Anonymous
No

I am using stlport 5.0. I have encountered a bug in
the when i assign a string the operator+ results of
two other strings.

If I assign to a string another string that is 24
characters long, stlport needs to allocate a piece of
memory from its allocator. to calculate that memory,
it adds one character to the strlen() calc for the
NULL terminator (it needs a 25 byte buffer) and then
rounds that up to 32 bytes in the allocator so that
it can re-use already allocated memory from the
allocator. when it puts that 24 character string in
that buffer, it doesn't put in the NULL until c_str()
is called, and then it puts in NULL terminator in the
25th byte. great.

Now with that exact string, if I now assign to it
another string that is exactly 24 characters long,
but instead of assigning it directly, it is a
concatenation of two other strings (using operator+),
then it winds up calling the _M_assign_sum function.
The logic in _M_assign_sum always reallocates a new
buffer "to avoid the self referencing trouble". The
way it decides the size of the new buffer is slighly
problematic. The logic looks at the current size(),
which is now 24 (because of the first string) as uses
that as a first guess to the required buffer size. it
then gets the required size from the __bstr_sum
object, which is also 24. it then checks if that
number exceeds the first guess of 24, and because it
does not, it only allocates 24 bytes for this string.
now, once c_str() is called, the NULL terminator gets
put into unallocated memory. because there is a good
chance this memory is allocated to another string, it
screws that up. if the other string is still valid
memory, then the other now becomes empty. if the
other string has been deallocated and now is
available in the allocator, the allocator uses the
buffer in it's linked list, so when it tries to re-
allocate that string buffer and must find the next
available buffer by using the "next" pointer, it is
an invalid pointer and causes a crash.

The seeming easy fix would be to add the 1 byte for
the NULL terminator when we are checking to see if
the _bstr_sum size exceeds to first guess of the
size, so that in this case it would realize that it
needs 25 bytes instead of thinking it only needs 24
bytes.

I have not tested this in any other version of
stlport, so it is possible that it is not a problem
in later versions.

Discussion

  • Petr Ovtchenkov

    Petr Ovtchenkov - 2006-09-11
    • priority: 5 --> 7
    • assigned_to: nobody --> complement
     
  • Petr Ovtchenkov

    Petr Ovtchenkov - 2006-09-12
    • status: open --> closed-works-for-me
     
  • Petr Ovtchenkov

    Petr Ovtchenkov - 2006-09-12

    Logged In: YES
    user_id=615813

    Test added into string_test.cpp, in trunk; issue not
    confirmed either with or without
    _STLP_USE_TEMPLATE_EXPRESSION.

     

Log in to post a comment.