VC STL - std::string and heap corruption

Author

std::string and heap corruption

2005-03-11, 8:59 am

Hello,

I am developing a program that uses std:string. I found that the
following code generates heap corruption error:

myfunct(inputdata &in)

{

std::string FileName in.getFileName();

FILE * fp=fopen(FileName.c_str(),"r");

}

what is the problem and how can I solve it?

I am using MSVC 7 on Windows XP professional.

Best regards

muchan

2005-03-11, 8:59 am

"muchan" <usenet@usenet.usenet> wrote in message
news:CxeYd.10109$F6.2016500@news.siol.net...
> MA wrote:
>
> maybe:
> std::string FileName = in.getFileName();
> ?
>
> you should show what the function in.getFileName() returns.

It return a std::string.

Regards

Tom Widmer

2005-03-11, 8:59 am

MA wrote:
> Hello,
>
> I am developing a program that uses std:string. I found that the
> following code generates heap corruption error:
>
>
>
> myfunct(inputdata &in)
>
> {
>
> std::string FileName in.getFileName();
>
> FILE * fp=fopen(FileName.c_str(),"r");
>
> }
>
>
>
> what is the problem and how can I solve it?

Well, I assume the function actually looks like this:
void myfunct(inputdata &in)
{
std::string FileName = in.getFileName();
FILE * fp=fopen(FileName.c_str(),"r");
}

The, that function itself looks fine, except for the resource leak of fp.

So, your problem lies in a different function. Remember, if you get a
heap corruption error, that corruption might have occurred in *any* code
that has executed up to the point that this function is called! Good luck.

Tom

muchan

2005-03-11, 4:03 pm

ma wrote:
>
>
> It return a std::string.
>
> Regards
>
>

You didn't notice the difference... 8(

You forgot the '=' and so your FileName wasn't assigned it got
whatever compiler thought you intended.

Or, if you forgot to type '=' only in your message,
(otherwise compile error results?)
then you need to debug what's going on in your inputdata::getFileName().

muchan

2005-03-11, 4:03 pm

Oh yes you are true I forgot the =.
I don't have the source code for getfilename as it come as a library. I
heard that if the configuration for lib creation and the project that I
working with aren't the same it would generate such errors. Is there any
such information?

Best regards

"muchan" <usenet@usenet.usenet> wrote in message
news:j4hYd.10116$F6.2016986@news.siol.net...
> ma wrote:
>
> You didn't notice the difference... 8(
>
> You forgot the '=' and so your FileName wasn't assigned it got
> whatever compiler thought you intended.
>
> Or, if you forgot to type '=' only in your message,
> (otherwise compile error results?)
> then you need to debug what's going on in your inputdata::getFileName().
>
> muchan

Ken Alverson

2005-03-11, 4:03 pm

"MA" <Not@Known.com> wrote in message
news:%23XkClwhJFHA.1176@TK2MSFTNGP15.phx.gbl...
>
> I am developing a program that uses std:string. I found that the
> following code generates heap corruption error:

What are you basing this assertion on? A tool like BoundsChecker, a message
from the runtime library, viewing something in the debugger? The symptom you
see may help isolate the problem.

If you are basing it on what you see in the debugger, you should be aware that
the debugger in vc7 is not smart enough to properly display std::strings. The
variable will be right, but the debugger will display garbage. That is
because the std::string included with vc7 uses an optimization for small
strings (<16 bytes, I think) in which it places the actual contents of the
string inside the std::string class, instead of a pointer to the string data.
When VC7's debugger encounters a long string, it tries to display the pointer
as if it were a string, resulting in what appears to be garbage.

Ken

Carl Daniel [VC++ MVP]

2005-03-11, 4:03 pm

MA wrote:
> Hello,
>
> I am developing a program that uses std:string. I found that the
> following code generates heap corruption error:
>
>
>
> myfunct(inputdata &in)
>
> {
>
> std::string FileName in.getFileName();

Does getFileName() comes from a DLL? If so, make sure that your EXE and the
DLL are both compiled with /MD (/MDd in debug builds) so you're both using
the DLL version of the runtime. If you don't do that, you can't pass
std::strings (or many other things) between the DLL and the EXE (or two
DLLs, whatever the case may be).

-cd

2005-03-11, 4:03 pm

getFileName comes from a library and I am creating a DLL.

I tested every combination of multithread debug and single thread but no
success

is it important that I am using MFC ad STL in the same project?

I have MSVC7 and I think ( but I am not sure) the library is build with
MSVC7.1. Is it important?

Best regards

"Carl Daniel [VC++ MVP]" <cpdaniel_remove_this_and_nospam@mvps.org.nospam>
wrote in message news:#63gH8kJFHA.2748@TK2MSFTNGP09.phx.gbl...
> MA wrote:
>
> Does getFileName() comes from a DLL? If so, make sure that your EXE and
the
> DLL are both compiled with /MD (/MDd in debug builds) so you're both using
> the DLL version of the runtime. If you don't do that, you can't pass
> std::strings (or many other things) between the DLL and the EXE (or two
> DLLs, whatever the case may be).
>
> -cd
>
>

Carl Daniel [VC++ MVP]

2005-03-11, 4:03 pm

ma wrote:
> getFileName comes from a library and I am creating a DLL.
>
>
> I tested every combination of multithread debug and single thread but
> no success
>
> is it important that I am using MFC ad STL in the same project?
>
> I have MSVC7 and I think ( but I am not sure) the library is build
> with MSVC7.1. Is it important?

Probably. Versions of STL and MFC are not binary compatible from release to
release. See if you can get a version of the library built with VC7, or
upgrade your own development to VC7.1.

-cd

2005-03-11, 9:00 pm

It generate a debug assert when it try to delete the string . By tracing the
program flow, I found that it is happening when on the destructor of the
string class.

Best regards

"Ken Alverson" <USENET.Ken@Alverson.net> wrote in message
news:eFKQfVkJFHA.3484@TK2MSFTNGP12.phx.gbl...
> "MA" <Not@Known.com> wrote in message
> news:%23XkClwhJFHA.1176@TK2MSFTNGP15.phx.gbl...
>
> What are you basing this assertion on? A tool like BoundsChecker, a
message
> from the runtime library, viewing something in the debugger? The symptom
you
> see may help isolate the problem.
>
> If you are basing it on what you see in the debugger, you should be aware
that
> the debugger in vc7 is not smart enough to properly display std::strings.
The
> variable will be right, but the debugger will display garbage. That is
> because the std::string included with vc7 uses an optimization for small
> strings (<16 bytes, I think) in which it places the actual contents of the
> string inside the std::string class, instead of a pointer to the string
data.
> When VC7's debugger encounters a long string, it tries to display the
pointer
> as if it were a string, resulting in what appears to be garbage.
>
> Ken
>
>

Markus Ewald

2005-04-06, 12:52 pm

ma wrote:
> Oh yes you are true I forgot the =.
> I don't have the source code for getfilename as it come as a library. I
> heard that if the configuration for lib creation and the project that I
> working with aren't the same it would generate such errors. Is there any
> such information?
>
First, the library has to be compiled wit hthe exact same compiler and
the same implementation of the Standard C++ Library (Borland's
std::string might be implemented totally different to Microsoft's
std::string and thus have another memory layout)

Second, if this library was compiled with the static runtime library,
the std::string's memory will be from the library's heap (place where
memory is allocated from), which is different from your application's -
thus resulting in a CRT assertion when your application tries to free
the memory and can't find the pointer on its heap.

>
> what is the problem and how can I solve it?
>
See above, I'd first try choosing the "Multithreaded DLL Debug" runtime
for debug builds and "Multithreaded DLL" runtime for release builds of
your project. If your linker doesn't choke on warnings, the 3rd party
library you're using has been compiled by a sane programmer. Otherwise,
well, otherwise the library is broken.

-Markus-

Markus Ewald

2005-04-06, 12:52 pm

MA wrote:
> It generate a debug assert when it try to delete the string . By tracing the
> program flow, I found that it is happening when on the destructor of the
> string class.
>
That's an indication that you're just using the wrong runtime library
setting. See my other post in this thread for an exlanation.

-Markus-

Sponsored Links