CString crashes in procedure

[Horst]

Hello,

I' pretty good at API but I got lost in an MFC-Problem with CString in one of my prodedures:

At return I get an exception. (Somethging about an assert in StringT)

I will show you the general setting:

BOOL Funtion (Param1, Param2, CString ShortDesc, CString Desc)
{
BOOL retval = FALSE;
CString FilePath;
CString DirectoryPath;

.....
Opening a File and storing the Data
.....
return retval; // <--- Here the crash occurs
}

Has anybody got an idea why this might happen?
And if its of relevance: I use some of CStrings methods to create a DirectoryPath from FilePath.

Do I have to use new or delete or something?

Hope you can help me!

Thanks!

Horst

[SeventhStar]

Originally posted by Horst
....
(Somethging about an assert in StringT)
....
I use some of CStrings methods

then make SOME code changes and it will be fixed!

be more specific, man!

[sbrothy]

I think you will have to post your code. Specifially, it would be interesting to know what you actually do to those poor CString instances :-). At a glance, it looks like your program crashes when the CString destructors are called. Perhaps you're somehow corrupting memory doing stuff you're not allowed to with the internal CString buffer..? And no, provided you use the CStrings as intended you shouldn't have to use neither new/delete.

[Mick]

Look

1. at the call stack and walk back up to find out why you are generating an 'at this point unknown' exception, my guess is access violation, which is typical.

Show

1. the exception.
2. the call stack.


And which is it, and exception or an ASSERT, two different things.

[Horst]

Ok, Ok,

I use strcpy to copy the description strings onto a structure.

Later I use FilePath.Format ("%s", CFile::GetFileName() ); to get the file path
Afterwards length = FilePath->ReverseFind('\\'); is used to get the length to the last Backslash.

I then use Format again to get the Path like:
DirectoryPath.Format ("%s", FilePath.left(length) );

All of this is encapsuled in the all famous TRY and CATCH statements but no exception is created until I reach the return statement.

And yes I've debugged it. The crash occures in the destructor of CString.

In my opinion this should be no problematic steps (This is why i left them out).

A and if it helps this is a save routine to create a file header for binary data and some data sets. Which means I use these Strings to:

1) Open a file
2) if there is no path create it


Does that help?

Horst

[Horst]

And Mick_2002 it's an exception obviously created by an assert type of ATLASSERT-makro and sorry I'm at work now and my code's at home so I cannot be more specific.

It's some Release function seemingly called by the destructor of CString down in StringT (whatever that is. My guess: Baseclass of CString).

Thanks for your answers anyway.
Even for those reminding me to give more precise info.

Horst

[SeventhStar]

Originally posted by Horst
Ok, Ok,
I use strcpy to copy the description strings onto a structure.

Later I use FilePath.Format ("%s", CFile::GetFileName() ); to get the file path
Afterwards length = FilePath->ReverseFind('\\'); is used to get the length to the last Backslash.

I then use Format again to get the Path like:
DirectoryPath.Format ("%s", FilePath.left(length) );

All of this is encapsuled in the all famous TRY and CATCH statements but no exception is created until I reach the return statement.

And yes I've debugged it. The crash occures in the destructor of CString.

In my opinion this should be no problematic steps (This is why i left them out).

A and if it helps this is a save routine to create a file header for binary data and some data sets. Which means I use these Strings to:

1) Open a file
2) if there is no path create it


Does that help?

Horst

whaaat?... i dont get a thing!
don you know that CString has predefined operatos =, + and +=

you must use
string1 = string2 instead of strcpy (NEVER USE strcpy WITH CString) there's no point in using Format in this scase either
string1 += string2 instead of strcat

as a whole forget about pointers to char when using CString, you obviosly caused some ugly memory mix-up that causes the exception when the destructor tries to delete the memory

and finaly:
PASTE YOUR CODE
dont just say: "first - this after that - that"
god knows what you might have written

[Horst]

**** you might be right.

I forgot about those **** opperators.

I'll give it a try thanks a lot.

Horst

[SeventhStar]

Originally posted by Horst
And Mick_2002 it's an exception obviously created by an assert type of ATLASSERT-makro and sorry I'm at work now and my code's at home so I cannot be more specific.

It's some Release function seemingly called by the destructor of CString down in StringT (whatever that is. My guess: Baseclass of CString).

Thanks for your answers anyway.
Even for those reminding me to give more precise info.

Horst

aha!
Try replacing all 'strcpy' with '=' and if it doesnt work. bring your code to your job and paste it here.

[Horst]

OK, for anyone intersted!

It had been a problem caused by the structure I used to store the data. I hat a version that used CString's and a version that had char-array's. And sadly VS was'nt able to determine the correct version of the header file.
I had a local one left and global one that should be used.

Thanks to all of you for your help.

Horst

[Mick]

Originally posted by Horst
And Mick_2002 it's an exception obviously created by an assert type of ATLASSERT-makro and sorry I'm at work now and my code's at home so I cannot be more specific.

It's some Release function seemingly called by the destructor of CString down in StringT (whatever that is. My guess: Baseclass of CString).

Thanks for your answers anyway.
Even for those reminding me to give more precise info.

Horst

True in a sense. Since int 3 is an exception, but ASSERT does not equal exception, in the sense that when someone says assert it's an evaluation, and not a throw. Sorry to be picky, but if someone says I have an exception, I don't think int 3, I think other exception types. If someone says ASSERT then I ask for the line of the assert to see what is being evaluated. Any way, glad you found your problem

#ifndef ATLASSERT
#define ATLASSERT(expr) _ASSERTE(expr)
#endif

#define _ASSERTE(expr) \
        do { if (!(expr) && \
                (1 == _CrtDbgReport(_CRT_ASSERT, __FILE__, __LINE__, NULL, #expr))) \
             _CrtDbgBreak(); } while (0)