Bug in Visual Studio 2005 compiler?

[a_matseevsky]

I have a solid guess, that it is a bug in compiler. Look at the next code: int xmin=max(xl1, max(xl2, xl3)); It works fine in the debug version, but gives me some nonsense in the release one. At that very time this variant works properly in both versions: int xmin=xl1; if(xmin

[CPallini]

a_matseevsky wrote:

but gives me some nonsense in the release one

What about providing some input/ouput in order to show us the nonsense?

Veni, vidi, vici.

[a_matseevsky]

OK, but I do not think, that it will make you happier. As a matter of fact, there was two similar lines of code: int xmin=max(il1, max(il2,il3)); int xmax=min(ir1, min(ir2,ir3)); The right variant was xmin=80, xmax=262. Wrong variant, presenting only in release version, was the next: xmin=76, xmax=38.

[CPallini]

Actually it would make me happier, anyway you did not provide the input values.

Veni, vidi, vici.

[Stefan_Lang]

Have you defined your own version of max() or are you using the one provided in some windows header? If the former, try commenting out that function and see if it still compiles in debug and/or release. If the latter, try defining your own function and see if it does compile in debug and/or release. As an alternative to either of the above you can try and #define NOMINMAX before including windows.h . This will prevent the macro definitions for min() and max(). These suggestions are based on the fact that MS provides macros for min() and max() in some Windows header, and that these macros might mess up code in unexpected ways. I know it did break std::valarray::min() and std::valarray::max() in VS 2003, and it did break std::min and std::max in later versions, until MS eventually fixed it.

GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

[a_matseevsky]

Thanks, boys, for yours comments, but I've just found the reason. And it did not make me happy. Really, great knowledge means great pain. Look at this small part of a stack frame: _lrct$ = -212 ; size = 16 tv5476 = -204 ; size = 8 Do you see something interesting here? A RECT structure of size 16 bytes and something too close to it- in fact, variable tv5476 partially overlaps RECT. And what command fst QWORD PTR tv5476[ebp] does? It rewrites half of my RECT. I can only hope, that it is the bug in my own Visual Studio. I'll reinstall it- may be, it will help (once I met something like tis- a "new" operator refused to work at all and re installation resolved this situation)

[Lost User]

I think you are reading that the wrong way round. The variable tv5476 is 8 bytes long starting at offset -204, so it goes from -204 to -212. The variable _lrct$ is 16 bytes from -212 to -228. Your problem is much more likely to be a bug in your code that only shows up in the release version, and that is far from uncommon. [edit] OK, my shoulders are broad enough to admit that I was wrong with that first statement. Lack of coffee/gin. [/edit]

Veni, vidi, abiit domum

[CPallini]

Richard MacCutchan wrote:

Your problem is much more likely to be a bug in your code that only shows up in the release version, and that is far from uncommon.

Yes. :thumbsup: However his actual code, like his I/O values are 'top secret'.

Veni, vidi, vici.

[Lost User]

:-D

Veni, vidi, abiit domum

[a_matseevsky]

You, boys, made my face red. Not because of me- you even do not know assembler. Command like mov [ebp-4], eax rewrites bytes from [ebp-4] UP to [ebp-1] . Just as fst QWORD PTR [ebp-204] does. RECT was allocated at [ebp-212], therefore its 16 bytes occupied addresses from ebp-212 to ebp-196. So simple. And aforementioned fst overwrote half of them. And BTW, I saw the whole process under debugger. My recommendation- any boy, who pretended to be a pro, must know assembler. I know what the mainstream in programming is- to replace pros by cheap yesterdays scholars. And it really does not me happy.

[Lost User]

Jolly good for you. You obviously won't need any help from us in the future then.

Veni, vidi, abiit domum

[a_matseevsky]

I need help. Question is, if any of you can give me some more or less valuable tip. When I asked my question the first time, I was not sure, that a bug really presents in Visual Studio. Now I know it. Problem is, what I have to do in such sorrowful situation. If someone else met such problem and fixed it, such person could share his experience. May be, this bug presents only in my own exemplar of Visual Studio- may be, it was damaged in some way and produces code with defects- in such case re-installation will solve this problem. Or such bug presents in each exemplar of Visual Studio 2005- in such case, I have to throw it away and buy 2008 or 2010. I know about a bug in Borland's compiler.

[Lost User]

a_matseevsky wrote:

I need help.

Then you could start by showing the actual code that is going wrong, as raised in your original question. Also you need to show the exact values of the variables that cause the problems, and the actual and expected result values.

Veni, vidi, abiit domum

[a_matseevsky]

I did it. Problem was caused by incorrect allocation of local variables in stack frame. This is what I hardly can change- it is a bug in compiler. The only important fact is that one value was replaced by another. Exact values of variables here mean nothing.

[Lost User]

If you continue to refuse to provide the information we have asked for, then there is no way we can offer any suggestions as to what may be wrong. If you are convinced that this is a compiler bug then you should collect all the information and send it to Microsoft.

Veni, vidi, abiit domum

[a_matseevsky]

I clearly demonstrated, what cased problem in particular. I can repeat it again. There was two local variables: _lrct$ = -212 ; size = 16 tv5476 = -204 ; size = 8 The next command rewrites 8 bytes of _lrct$ fst QWORD PTR tv5476[ebp] That's all info. Which data in particular was replaced and by what- means nothing. The only important fact is that data was replaced with something else.

[Lost User]

You have not clearly demonstrated anything. Unless we see the source code there is nothing we can suggest. And, as I said before, if you are convinced that this is a compiler bug, then you should be sending it to Microsoft.

Veni, vidi, abiit domum

[jschell]

a_matseevsky wrote:

Any idea how could it be?

Perhaps nonstandard compiler options or linker options. And I am rather certain that max() is a macro. Which means that the only possible source of the problem would be an optimization. Excluding of course some pointer bug, which could cause almost any problem. And I am also certain that you could write a trivially small program that would demonstrate this, which is basically what has already been asked. If you cannot in fact demonstrate the same problem with the trivial program then it would point to some other problem in your application.

[a_matseevsky]

There is no way to demonstrate problem, if compiler is unstable. problem disappeared, when I replaced max() and min(), but occurred again after some insignificant change in code (which was made far from the procedure, where problem occurred!). I used default compiler's options. Later, when I was looking for the source of the problem, I created database and set /Zi switch for the release version. After these actions I was able to find the very command, which destroyed my data. The next was trivial- I find offsets of local variables and noticed, that some of them was incorrectly placed (one partially overlaps another). This is the bug in compiler, not mine.

[Lost User]

a_matseevsky wrote:

This is the bug in compiler, not mine.

Then go and tell Microsoft about it, as I already suggested, since you refuse to show us any of the code which causes the problem.

Veni, vidi, abiit domum