|
Yes, but do you say char * pResult; , or do you say char * pResult = new char [255]; , for example ?
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
"I'm thinking of getting married for companionship and so I have someone to cook and clean." - Martin Marvinski, 6/3/2002
|
|
|
|
|
As Christian suggests the definition of 'result' is most likely where the problem lie.
Debug builds initialize the stack, heap etc. whereas release builds don't, which is one of the reasons they behave differently.
Neville Franks, Author of ED for Windows. www.getsoft.com
|
|
|
|
|
Ok.
But this is an initialization:
strcpy(result,"anystring");
Then:
strcat(result,s1);
should append 's1' to 'result', instead it appends the other string 's2' to 'result'...
it has to do with Opt/MazimixeSpeed, that in Debug build is Disabled, but for a such simple task I don't figure out why causes this strange effect...
|
|
|
|
|
Yes, new char[255], is a string, vector of chars. I use Buggy() this way:
void CBugDlg::OnButton1()
{
char* test = new char[255];
Buggy(test);
m_sTest = test;
delete [] test;
UpdateData(FALSE);
}
or
void CBugDlg::OnButton1()
{
char test[255];
Buggy(test);
m_sTest = test;
UpdateData(FALSE);
}
The bug vanishes if I turn Optimizations\MaximixeSpeed to Optimizations\Default. But this still sucks... I must know why
|
|
|
|
|
There is your problem - m_sText = test means both variables point to the same allocated data, which delete [] test will delete. You should also always set deleted pointers to NULL.
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
"I'm thinking of getting married for companionship and so I have someone to cook and clean." - Martin Marvinski, 6/3/2002
|
|
|
|
|
Sorry, I did not specify, but m_sTest is a CString object (DDX for a CEDit), so it copies 'test' and there should be no problems about it.
|
|
|
|
|
are you allocating memory for result???
Nish
My miniputt high is now 29
I do not think I can improve on that
My temperament won't hold
www.busterboy.org
|
|
|
|
|
Yes... try the test project if you can, try Debug and Release, pressing the button: it gives no errors, but two different outputs
http://digilander.iol.it/ilbanca/fuffa/Bug.zip
|
|
|
|
|
I am puzzled.
It worked fine.
Both in release and in debug
Nish
My miniputt high is now 29
I do not think I can improve on that
My temperament won't hold
www.busterboy.org
|
|
|
|
|
Grrr.... I'm running WinXP, what your OS ?
|
|
|
|
|
Frankesk wrote:
Grrr.... I'm running WinXP, what your OS ?
I ran it on XP [both debug and release] without any problems at all.
Nish
My miniputt high is now 29
I do not think I can improve on that
My temperament won't hold
www.busterboy.org
|
|
|
|
|
Your code works fine for me as well in both Debug and Release builds on WinXP Pro. That is I "anystringabcde"
Have you tried rebooting Windows? If all else fails...
Neville Franks, Author of ED for Windows. www.getsoft.com
|
|
|
|
|
This is a very strange problem...
rebooted, underclocked the processor, I have no idea... it still gives me different results:
In Debug "anystringabcde"
In Release "anystringBUG!"
When Optimizations is MazimizeSpeed(default setting)
Thanks for your time
|
|
|
|
|
Have you tried stepping through it in the debugger and seeing where 'result' screws up. You can still debug release builds by including debug info. I think there is an article by Mr. Newcomer here on CP about this.
Neville Franks, Author of ED for Windows. www.getsoft.com
|
|
|
|
|
I have found the article, thanks! Very interesting http://www.codeproject.com/debug/survivereleasever.asp)
But life is hard: I have turned on debugging information for Release and the compiler gives me this error asa I press F5:
"Command line error D2016 : '/ZI' and '/O2' command-line options are incompatible"
/O2 is the parameter for the Optimization->MazimixeSpeed, and if I turn it OFF the bug doesn't appear, so debugging is useless in this case! Nice...
Maybe I have to reinstall, I don't know
|
|
|
|
|
You can still debug but you'll need to be able to work through the Assembler code. If you started with Assembler like I did this isn't too difficult.
Another option is to use: OutputDebugString()
Neville Franks, Author of ED for Windows. www.getsoft.com
|
|
|
|
|
Debugging assembler is a dying skill.
Thank god I learned it years and years ago. I use that skill all the time.
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
|
Tim Smith wrote:
Debugging assembler is a dying skill.
Thank god I learned it years and years ago. I use that skill all the time.
Yes I couldn't agree more. My guess is that these days most programmers wouldn't have a clue about Assembler.
I started programming in Signetics 2650 Assembler with 8K RAM, and spent a number of years writing Z80/8080 Assembler. In fact the very first versions of my programmers editor (ED) were writtem in 2650 Assembler. It sure has come an awefully long way to what you see today. Thank god for C/C++, but having said that I still dip in to the Assembler listings from time to time while debugging.
I would also take a punt and say many developers today don't use a Debugger enough.
Neville Franks, Author of ED for Windows. www.getsoft.com
|
|
|
|
|
I learned on the 8080/85, Z80, and 6809 processors.
Ah, the good old days.
My first C compiler was ECO-C. This was back in the days when a C compiler generated ASM code which you then sent into the assembler.
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
|
I have a little experience with ASM, learnt at Uni and played at home, I'll give a look at it but maybe another problem has come out.
I have installed WinXP few weeks ago and I notice that no symbols are found during debugging. Maybe I have to download this 150MB package from MS site (windowsxp.x86.fre.rtm.symbols.exe)
Another strange thing appened: if I put AfxMessageBox(s1) before strcpy(), the bug vanishes:
void Buggy( char* result )
{
char s1[6];
char s2[5];
strcpy(s1,"abcde");
strcpy(s2,"BUG!");
AfxMessageBox(s1);
// DOESNT WORK
strcpy(result,"anystring");
strcat(result,s1);
}
It displays "abcde" and 'result' is filled with "anystringabcde". If I comment out AfxMessageBox(s1) 'result' is filled with "anystringBUG!".
I have made several programs, some little, others bigger, but I had never seen these strange beahviours, especially because on other PCs compiles fine. I must admit that I'm not expert in debugging, I prefer to proceed slowly, and run the program just after having added/removed some lines of code.
Lately I have installed and removed MySQL, MSDE, various ServicePacks, maybe something has been wrong and I didn't notice.
|
|
|
|
|
Frankesk wrote:
Lately I have installed and removed MySQL, MSDE, various ServicePacks, maybe something has been wrong and I didn't notice.
Maybe one of the MFC DLL's has gone back to an old version. About now I'd suggest re-installing VC++.
Neville Franks, Author of ED for Windows. www.getsoft.com
|
|
|
|
|
I have reinstalled, now all works...
Thanks for your time
|
|
|
|
|
Memory in debug mode is buffered so that memory overflow conditions that can crash in release mode can work fine in debug mode. My first guess is that 'result' does not point to a block of memory of the size you are expecting. Are you sure you allocated sufficient memory for the trailing null character? result will need to point to at least 16 bytes of memory for this code to work properly ( "anything" = 9 s1 = 6 NULL char = 1.)
"There's a slew of slip 'twixt cup and lip"
|
|
|
|
|
Yes it was large enough, 255 chars. The problem is that doesnt crash, but display a string contained in another char-vector, as if they did overlapped, I don't know.
I thought of a NULL terminating that I could have missed so that the string 1 could extend to string 2 that was declared just after, but it's not the case. Turing Optimizations to Default fixes this bug on my machine, while in other pcs runs fine without altering this setting
|
|
|
|
|
Sorry, I did not read the last line in your original post, so I misunderstood the nature of the bug. It sounds to me as though you have a damaged stack. The issue is *still* one of debug mode buffering memory more generously than release mode. You are going to need to trace back through the call stack to figure out where the problem is. Stack overflow bugs can cause all kinds of bizarre issue like this. Good hunting.
"There's a slew of slip 'twixt cup and lip"
|
|
|
|