commenting no-op lines lead to wrong results

[julien.durand.1981]

hi,

I'm just having a weird problem that I can't explain by myself and
would appreciate someone else's view on this piece of code (used in a
JNI project). Basically if I remove some no-op lines the compiled
library does not produce a valid result (does not load the file). I
suspect that this can come from an error in the compile/linking chain
but can't spot it... Has anyone already face something like that ? :

void Store::load(const string& filename){
ifstream is(filename.c_str(), ios::binary | ios::in);
DataInputStream dis(&is);
Vector v;
bool test;
while(dis>>v){
addVector(v);

//no-op!!!!!!
test=false;
}
is.close();


int i=0;

//no-op!!!!!!!
cout<<dis<<" "<<i<<" "<<" "<<endl;
}

cheers

 

[Victor Bazarov]

I'm just having a weird problem that I can't explain by myself and
would appreciate someone else's view on this piece of code (used in a
JNI project). Basically if I remove some no-op lines

They are not "no-op", they are "unimportant", maybe. Remember that
'cout <<' has *side effects*, and accessing a variable can affect how
CPU cache is managed (although this is not defined in the language,
of course).

the compiled
library does not produce a valid result (does not load the file). I
suspect that this can come from an error in the compile/linking chain
but can't spot it... Has anyone already face something like that ? :

Yes, plenty of examples when compiler is at fault and generates wrong
code for the program, especially if the optimizer is overly aggressive.

Try disabling optimizations and then step them up by one level and stop
when the problem shows up. Use the last optimization level on which
there was no problem.

[..]

V

 

[Tom Widmer]

hi,

I'm just having a weird problem that I can't explain by myself and
would appreciate someone else's view on this piece of code (used in a
JNI project). Basically if I remove some no-op lines the compiled
library does not produce a valid result (does not load the file). I
suspect that this can come from an error in the compile/linking chain
but can't spot it... Has anyone already face something like that ? :

void Store::load(const string& filename){
ifstream is(filename.c_str(), ios::binary | ios::in);
DataInputStream dis(&is);
Vector v;
bool test;
while(dis>>v){
addVector(v);

//no-op!!!!!!
test=false;
}
is.close();


int i=0;

//no-op!!!!!!!
cout<<dis<<" "<<i<<" "<<" "<<endl;
}

Most often this will be due to a bug in your code, such as stack
corruption, which is hidden by the presence of the no-op lines. In this
case, are you sure that the Vector class is correct? And the addVector
function? What happens when you step through it with a debugger?

Of course, it could be a compiler bug, but that's much less likely.

Tom

 

[julien.durand.1981]

hi,

thank you very much for your remarks, all of them very valid indeed.
I've just realised that I could have been a little bit more complete on
this case...

First of all, most of my other classes are quite simple or
autogenerated by some sort of compiler compiler (wich might itself be
buggy but quite unlikely for the class inlvoved here). I've been using
them for quite a while without much trouble.

I have a set of unit test cases that passes ok with all optimization
levels from -O0 to -O2... The problem only occurs when I linked against
a set of other objects files to produce a JNI library for a java
project.

To be more precise everything is OK if I compile all other files with
-O2 and only this file with -O0... unless I keep those *useless* lines
in wich case -O2 is fine...

I can move the lines around... but can't remove them (which let me
think that it might not be a corruption of the heap...it's also the
very first thing my library does wich mean that such a corruption would
very likely be internal to this function which would also make the unit
test fail).

It becomes tricky due to the fact that the bug only occurs when the
code is loaded in the JVM and I have yet to learn how to attach a JVM
process to gdb and trigger a breakpoint when necessary...

I could of course keep -O0 but I was coding in c++ (and even assembly)
to get the more juice my machine could give me!!!!

Anyway I'm going to test that on a different tuple os/compiler/binutils
versions... maybe it will give me some hints.

cheers

 

[julien.durand.1981]

If my stack is corrupted it can only comes from within the call tree of
this function isn'it ?
or can it propagate throught bad alloc/desallocation on the top of the
stack ? ie can the stack be corrupted after the bad function have
returned ?

 

[Ron Natalie]

//no-op!!!!!!
test=false;

This is hardly a noop. test had an indeterminate value
before this. Stupid braindamaged C++ behavior of skipping
default initialization in certian cases.

 

[Alf P. Steinbach]

* (e-mail address removed):

It becomes tricky due to the fact that the bug only occurs when the
code is loaded in the JVM and I have yet to learn how to attach a JVM
process to gdb and trigger a breakpoint when necessary...

That's a likely culprit then. You have static type checking all the way
up to the JVM interface, a discontinuity right there with no type
checking whatsoever, and dynamic type checking above that (in Java).
Guess where you might have used incorrect types or number of args?