System reboot/system freeze with simple code in Visual C++ 6 and lcc-win32 (OS issue?)

[Wagner Dias]

Hi,

The following code causes either a system reboot or a system freeze
after around 15-20 minutes.

The code was compiled in Visual C++ 6.0, as well as in lcc-win32 (with
proper replacement of new/delete with malloc/free), latest version as
of Mar 28, 2005, in the following system:

Microsoft Windows XP Professional
Version 2002
Service Pack 1

running on an

AMD Athlon XP 1900+ 1.6 GHz
512MB RAM

This seems like a OS-related issue, since this code causes reboot or
freeze when generated by both compilers.

Any help is appreciated, thanks in advance,

Wagner


=========================

double intersection_size(const unsigned int *A, unsigned int szA,
const unsigned int *B, unsigned int szB)
{
double wresult = 0.0;

// Obs: the elements must be ordered.
unsigned int ii, jj;
for (ii = 0, jj = 0; ii < szA && jj < szB; ) {
unsigned int a, b;
a = A[ii];
b = B[jj];

// the element pointed by ii is in the intersection
if (a == b) {
wresult += 1.0;
ii++;
jj++;
}
// the element pointed by ii is in A but not in the intersection
else if (a < b) {
ii++;
}
// the element pointed by jj is in B but not in the intersection
else {
jj++;
}
}
return wresult;
}

int main(void)
{
unsigned int *v1, *v2;

v1 = new unsigned int[3000];
v2 = new unsigned int[3000];

for (unsigned int i = 0; i < 3000; i++) {
v1 = i;
v2 = i+1500;
}

for ( ; ; ) intersection_size(v1, 3000, v2, 3000);

delete [] v1;
delete [] v2;

return 0;
}

=========================

 

[Andre Kostur]

(e-mail address removed) (Wagner Dias) wrote in

Hi,

The following code causes either a system reboot or a system freeze
after around 15-20 minutes.
[snip]

double intersection_size(const unsigned int *A, unsigned int szA,
const unsigned int *B, unsigned int szB)

Uh, why bother with a "double" return since you cannot have anything
bigger than an unsigned int returned anyway? (Assume _every_ element in A
is in B... your variable for declaring the size of A is an unsigned int,
thus your answer can be no larger than an unsigned int....)

{
double wresult = 0.0;

// Obs: the elements must be ordered.
unsigned int ii, jj;
for (ii = 0, jj = 0; ii < szA && jj < szB; ) {
unsigned int a, b;
a = A[ii];
b = B[jj];

// the element pointed by ii is in the intersection
if (a == b) {
wresult += 1.0;
ii++;
jj++;
}
// the element pointed by ii is in A but not in the intersection
else if (a < b) {
ii++;
}
// the element pointed by jj is in B but not in the intersection
else {
jj++;
}
}
return wresult;
}

Stylistic note, I'd change all of those post-increments to pre-
increments. Probably will result in no difference when dealing with
ints, but may make a difference if you are dealing with more complex
classes.

int main(void)
{
unsigned int *v1, *v2;

v1 = new unsigned int[3000];
v2 = new unsigned int[3000];

Why bother with the dynamic memory? Why not simply declare the arrays as
local variables? (And if the answer is "because the real code uses much

for (unsigned int i = 0; i < 3000; i++) {
v1 = i;
v2 = i+1500;
}

OK.. populates the arrays with the values 0...2999, and 1500...4499. So
with this algorithm I guess you're expecting a return of 1500?

for ( ; ; ) intersection_size(v1, 3000, v2, 3000);

So your program will spend forever re-executing intersection_size....
why?

delete [] v1;
delete [] v2;

return 0;
}

=========================

 

[Victor Bazarov]

[...]
So your program will spend forever re-executing intersection_size....
why?

Even considering other notes, the answer is "because". The program is
valid, no undefined behaviour should be produced. The OS probably barfs
because the CPU is used too much during too long by the same process.
Nothing can really be said except "don't do that". But still it all falls
under the OS (platform) topicality, and all we here can conclude that from
the C++ point of view, all is well.

To the OP: try it under a different OS, like Linux and see how long it
takes to make it reboot/freeze.

V

 

[Andre Kostur]

[...]
So your program will spend forever re-executing intersection_size....
why?

Even considering other notes, the answer is "because". The program is
valid, no undefined behaviour should be produced. The OS probably
barfs because the CPU is used too much during too long by the same
process. Nothing can really be said except "don't do that". But still
it all falls under the OS (platform) topicality, and all we here can
conclude that from the C++ point of view, all is well.

OK.. my question was more rhetorical and was intended to prompt the OP to
examine whether he really wanted an infinite loop in the program. However,
I do agree with you. From a C++ standpoint there was nothing fundamentally
wrong with the program.