Author: Miguel A. Ballicora
Date: 15:46:57 11/28/01
Go up one level in this thread
On November 28, 2001 at 16:40:22, Scott Gasch wrote:
>On November 28, 2001 at 11:46:45, Miguel A. Ballicora wrote:
>
>>ASSERT( "Message"[0] != '\0' );
>>
>>Looks like "Message" is a pointer to char that is not initialized to 'M' as it
>>should be.
>>
>>Another try that fail is
>>
>>char tmp[256];
>>strcpy(tmp, "Another Message\n");
>>ASSERT(tmp[0]!='\0');
>
>Something is utterly broken here and I really doubt it's the compiler. Such
>simple cases almost certainly work. Here's my advice to you: get rid of your
>assert macro (could you have written it incorrectly?) and do a simple
>if-statement... then put a breakpoint at the strcpy and single step the code
>watching the memory at &tmp. Another thought: are you building this test in
>retail mode (and therefore the ASSERT is not in the code gen)? Also beware of
>smart compilers simply removing identifiers you don't need. I don't think this
>is relevant here though.
>
>>That is why if I try to do this simple line:
>>
>>printf("Another Message\n");
>>
>>I got the same as
>>
>>printf("\0");
>>
>>Similar behavior is I use fprintf, sprintf etc. It is the string that
>>is messed up and initilized as an empty string!
>>
>>That might be related to the original problem. I had an array initialized
>>that returned me zeros. What the heck am I doing wrong? I have no idea.
>>Not having the chance to use printf as a debugging tool drives me nuts.
>>When I do a debugging session everything is normal (at least with printf,
>>I did not go further).
>
>You have to be somehow zeroing out your memory buffer by accident. My advice to
>you is to either put a watch on that buffer or single step your program keeping
>an eye on that buffer as you do. I bet you'll find you're somehow klobbering
>it. If your problem doesn't reproduce in a debugger you can try memory
>protection to catch this problem... but the odds are that allocating your buffer
>from the heap or with VirtualAlloc will cause your layout in virtual memory to
>change and therefore probably hide the problem. Speaking of which, does the
>problem go away when you change the order of identifier declarations? If so its
>almost certain that you are overrunning a buffer and zeroing something else.
Thanks guys, all of you (Dieter and Eugene too) think that the problem is
related to that. I agree, and tonight after work I will check that hypothesis.
>Triple check any ZeroMemory calls or memset calls you make... are you absolutely
>sure you are only hitting what you want?
The good news is that this problem occurs at the beginning of the function
xboard(), so, there is no much code that is executed before xboard() called.
Most of it is initialization!. I think that the first thing I should do is
to check carefully all that code and add asserts like crazy. It won't be
wasted time because those asserts are always useful.
The funny thing is that whatever the bug is, it has been hidden for a year.
Now exploded when I tried to rewrite xboard(). If I put back the old
file xboard.c everything looks normal... I gotta get to the bottom of this.
[snip]
>Good luck. I know this is frustraiting but keep after it. And let us know what
>you found (even if its a dumb mistake). That way we can learn from your
Yes I will.
>experience! I'd much rather learn from yours than my own, less work that way.
There is one advice from GM Arnold Denker that I read somewhere:
"Shave in other people faces" so you test your shaving technique :-)
Regards,
Miguel
>If you really have a compiler bug and can reproduce it with a small bit of code,
>post it up here and I'll try it on my MSVC6.0 (and newer MSVCs) and report the
>results. I bet Eugene might be interested in this sort of thing too.
>
>Scott
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.