sort() causes crash in release mode 
Author Message
 sort() causes crash in release mode

Hi,

I have the following statement in my source:

sort(vecVectors.begin(), vecVectors.end());

My program *sometimes* crashes  in release mode on this statement but never
in debug mode. I have had this kind of problems before with sort(). Does
anybody have an idea what I am doing wrong?

Some extra info:

vector <TVector3D> vecVectors

typedef /* [uuid] */ struct  TVector3D
    {
    float x;
    float y;
    float z;
    } TVector3D;

bool operator<(const TVector3D &v0, const TVector3D &v1)
{
 return (v0.x < v1.x) ||
   (v0.x == v1.x && ((v0.y < v1.y) ||
   (v0.y == v1.y && v0.z < v1.z)));

Quote:
}

Thanks in advance,
Kurzweil


Sat, 02 Apr 2005 21:56:34 GMT  
 sort() causes crash in release mode
Can it be that some component of some element is NaN? NaN has a property
of breaking the comparison trichotomy - if either a or b is NaN, a<b,
b<a and a==b are all false. That would make your operator< not a strick
weak ordering, which seriously confuses sort().
--
With best wishes,
    Igor Tandetnik

"For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken


Quote:
> Hi,

> I have the following statement in my source:

> sort(vecVectors.begin(), vecVectors.end());

> My program *sometimes* crashes  in release mode on this statement but
never
> in debug mode. I have had this kind of problems before with sort().
Does
> anybody have an idea what I am doing wrong?

> Some extra info:

> vector <TVector3D> vecVectors

> typedef /* [uuid] */ struct  TVector3D
>     {
>     float x;
>     float y;
>     float z;
>     } TVector3D;

> bool operator<(const TVector3D &v0, const TVector3D &v1)
> {
>  return (v0.x < v1.x) ||
>    (v0.x == v1.x && ((v0.y < v1.y) ||
>    (v0.y == v1.y && v0.z < v1.z)));
> }

> Thanks in advance,
> Kurzweil



Sat, 02 Apr 2005 22:21:37 GMT  
 sort() causes crash in release mode
Just throwing out ideas, but besides the obvious ways to generate NaN
(undefined math operations) you might end up with a NaN if you simply
forget to initialize a TVector3D somewhere.  Try adding a default
constructor that sets the components to zero and see if the problem goes
away.

Ken


Quote:
> Can it be that some component of some element is NaN? NaN has a
property
> of breaking the comparison trichotomy - if either a or b is NaN, a<b,
> b<a and a==b are all false. That would make your operator< not a
strick
> weak ordering, which seriously confuses sort().
> --
> With best wishes,
>     Igor Tandetnik

> "For every complex problem, there is a solution that is simple, neat,
> and wrong." H.L. Mencken



> > Hi,

> > I have the following statement in my source:

> > sort(vecVectors.begin(), vecVectors.end());

> > My program *sometimes* crashes  in release mode on this statement
but
> never
> > in debug mode. I have had this kind of problems before with sort().
> Does
> > anybody have an idea what I am doing wrong?

> > Some extra info:

> > vector <TVector3D> vecVectors

> > typedef /* [uuid] */ struct  TVector3D
> >     {
> >     float x;
> >     float y;
> >     float z;
> >     } TVector3D;

> > bool operator<(const TVector3D &v0, const TVector3D &v1)
> > {
> >  return (v0.x < v1.x) ||
> >    (v0.x == v1.x && ((v0.y < v1.y) ||
> >    (v0.y == v1.y && v0.z < v1.z)));
> > }

> > Thanks in advance,
> > Kurzweil



Sat, 02 Apr 2005 22:28:09 GMT  
 sort() causes crash in release mode
    I have found that 95% of the time when it crash in release, but not
debug, it's because you've overrun an array.  vectors are just arrays with a
few nice features added, but you can still over run them.  Is enough space
reserved()?  Do you add items with [] or push_back()?

--
Truth,
James Curran
www.NovelTheory.com  (Personal)
www.NJTheater.com   (Professional)
www.aurora-inc.com   (Day job)


Quote:
> Hi,

> I have the following statement in my source:

> sort(vecVectors.begin(), vecVectors.end());

> My program *sometimes* crashes  in release mode on this statement but
never
> in debug mode. I have had this kind of problems before with sort(). Does
> anybody have an idea what I am doing wrong?

> Some extra info:

> vector <TVector3D> vecVectors

> typedef /* [uuid] */ struct  TVector3D
>     {
>     float x;
>     float y;
>     float z;
>     } TVector3D;

> bool operator<(const TVector3D &v0, const TVector3D &v1)
> {
>  return (v0.x < v1.x) ||
>    (v0.x == v1.x && ((v0.y < v1.y) ||
>    (v0.y == v1.y && v0.z < v1.z)));
> }

> Thanks in advance,
> Kurzweil



Sun, 03 Apr 2005 00:12:50 GMT  
 sort() causes crash in release mode


Quote:
> Hi,

> I have the following statement in my source:

> sort(vecVectors.begin(), vecVectors.end());

> My program *sometimes* crashes  in release mode on this statement but never
> in debug mode. I have had this kind of problems before with sort(). Does
> anybody have an idea what I am doing wrong?

In addition to the possible problems with NaN's
mentioned by others, your comparison is flawed
as described below.

Quote:
> Some extra info:

> vector <TVector3D> vecVectors

> typedef /* [uuid] */ struct  TVector3D
>     {
>     float x;
>     float y;
>     float z;
>     } TVector3D;

> bool operator<(const TVector3D &v0, const TVector3D &v1)
> {
>  return (v0.x < v1.x) ||
>    (v0.x == v1.x && ((v0.y < v1.y) ||
>    (v0.y == v1.y && v0.z < v1.z)));
> }

You've taken a shortcut which ends up not
defining a weak ordering.  It should be
  return (v0.x < v1.x) ||
    (v0.x == v1.x && ((v0.y < v1.y) ||
    (v0.x == v1.x && v0.y == v1.y && v0.z < v1.z)));

Consider the (x,y,z) triples a=(3, 1, 2) , b=(2, 1, 3).
With your compare, a < b and b < a are both true.
That is likely to confuse any sorting algorithm.

--
-Larry Brasfield
(address munged, s/sn/h/ to reply)



Sun, 03 Apr 2005 02:00:17 GMT  
 sort() causes crash in release mode

Quote:

> > bool operator<(const TVector3D &v0, const TVector3D &v1)
> > {
> >  return (v0.x < v1.x) ||
> >    (v0.x == v1.x && ((v0.y < v1.y) ||
> >    (v0.y == v1.y && v0.z < v1.z)));
> > }

> You've taken a shortcut which ends up not
> defining a weak ordering.  It should be
>   return (v0.x < v1.x) ||
>     (v0.x == v1.x && ((v0.y < v1.y) ||
>     (v0.x == v1.x && v0.y == v1.y && v0.z < v1.z)));

> Consider the (x,y,z) triples a=(3, 1, 2) , b=(2, 1, 3).
> With your compare, a < b and b < a are both true.
> That is likely to confuse any sorting algorithm.

No, I think his predicate is ok; it's just a little confusing to read -
watch the parenthesis...Peronsally, I'd probably write it this way:

if (v0.x < v1.x) return true; if (v1.x < v0.x) return false;
if (v0.y < v1.y) return true; if (v1.y < v0.y) return false;
if (v0.z < v1.z) return true; if (v1.z < v0.z) return false;
return false;

As long as you keep your 0s, 1s, Xs, Ys, and Zs straight you're unlikely
to make a mistake that way, since everything follows the same pattern.
I suspect performance will be virtually identical.

Ken



Sun, 03 Apr 2005 02:30:01 GMT  
 sort() causes crash in release mode

Quote:

> >  return (v0.x < v1.x) ||
> >    (v0.x == v1.x && ((v0.y < v1.y) ||
> >    (v0.y == v1.y && v0.z < v1.z)));

> You've taken a shortcut which ends up not
> defining a weak ordering.  It should be
>   return (v0.x < v1.x) ||
>     (v0.x == v1.x && ((v0.y < v1.y) ||
>     (v0.x == v1.x && v0.y == v1.y && v0.z < v1.z)));

I don't see the difference, but it's easy to get lost in the (mostly
unnecessary) parentheses (the indentation is a bit misleading, too). In
particular, the '((' in the second line means you only get to the third
line when v0.x == v1.x, so the first test in the third line is
redundant. The full long form (i.e. your version with minimal
parenthesization) would be:

return v0.x < v1.x ||
v0.x == v1.x && v0.y < v1.y ||
v0.x == v1.x && v0.y == v1.y && v0.z < v1.z;

To eliminate the redundant equality test on the x components:

return v0.x < v1.x ||
            v0.x == v1.x &&
                (v0.y < v1.y || v0.y == v1.y && v0.z < v1.z);

(I've adjusted the indentation to reflect the grouping a bit more
accurately)

Quote:
> Consider the (x,y,z) triples a=(3, 1, 2) , b=(2, 1, 3).
> With your compare, a < b and b < a are both true.

Looks to me like a < b is false in both forms. With the original
version:

return (3 < 2) ||
   (3 == 2 &&
        ((1 < 1) || (1 == 1 && 2 < 3)));

Here, the first line is false, so we have to look at the second to
determine the result of the || in the first line. In the second line, 3
== 2 is false, so the result of the && in that line is false. That means
the || in the first line is also false, so the value of the expression
is false.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)



Sun, 03 Apr 2005 02:36:49 GMT  
 sort() causes crash in release mode


Quote:

> > >  return (v0.x < v1.x) ||
> > >    (v0.x == v1.x && ((v0.y < v1.y) ||
> > >    (v0.y == v1.y && v0.z < v1.z)));

> > You've taken a shortcut which ends up not
> > defining a weak ordering.  It should be
> >   return (v0.x < v1.x) ||
> >     (v0.x == v1.x && ((v0.y < v1.y) ||
> >     (v0.x == v1.x && v0.y == v1.y && v0.z < v1.z)));

> I don't see the difference, but it's easy to get lost in the (mostly
> unnecessary) parentheses (the indentation is a bit misleading, too).

[snip]

You and Ken are right, of course.  I misread
the parenthesis after too quickly believing
the grouping and indentation meant more than
it does to the compiler.

I'm reminded of a comical instance of arrogance
I once observed in another developer.  I had
cause to modify a complex conditional in his
code, (to fix a bug assigned to me), and since
its complexity and poor formatting had led to
the bug, I reformatted to make its structure
clear.  (I reformatted it as part of becoming
able to understand the bug and its correction.)
Since we were near release, all mods had to be
reviewed by at least one additional person.  I
chose him for obvious reasons.

His first step, even before considering the
change, was to reformat it, collapsing it
from 5 or 6 lines with combinations of 1 and
2 spaces to indicate sublevels to 2 closely
packed lines with the line break at whatever
token column 80 happened to break off.  He
could not even comprehend that the more
logical format would ease our discussion of
why it was a bug and why the fix was right.
We spent extra minutes discussing (arguing,
actually) what the structure was before.

Incidents like that helped me to understand
I was working with the wrong people.

--
-Larry Brasfield
(address munged, s/sn/h/ to reply)



Sun, 03 Apr 2005 05:09:49 GMT  
 sort() causes crash in release mode

Quote:

> You and Ken are right, of course.  I misread
> the parenthesis after too quickly believing
> the grouping and indentation meant more than
> it does to the compiler.

I've never done anything remotely like that. <g>

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)



Sun, 03 Apr 2005 05:51:37 GMT  
 sort() causes crash in release mode
Many, many thanks you all. It was a NaN that messed up the sort().

Kurzweil


Quote:
> Can it be that some component of some element is NaN? NaN has a property
> of breaking the comparison trichotomy - if either a or b is NaN, a<b,
> b<a and a==b are all false. That would make your operator< not a strick
> weak ordering, which seriously confuses sort().
> --
> With best wishes,
>     Igor Tandetnik

> "For every complex problem, there is a solution that is simple, neat,
> and wrong." H.L. Mencken



> > Hi,

> > I have the following statement in my source:

> > sort(vecVectors.begin(), vecVectors.end());

> > My program *sometimes* crashes  in release mode on this statement but
> never
> > in debug mode. I have had this kind of problems before with sort().
> Does
> > anybody have an idea what I am doing wrong?

> > Some extra info:

> > vector <TVector3D> vecVectors

> > typedef /* [uuid] */ struct  TVector3D
> >     {
> >     float x;
> >     float y;
> >     float z;
> >     } TVector3D;

> > bool operator<(const TVector3D &v0, const TVector3D &v1)
> > {
> >  return (v0.x < v1.x) ||
> >    (v0.x == v1.x && ((v0.y < v1.y) ||
> >    (v0.y == v1.y && v0.z < v1.z)));
> > }

> > Thanks in advance,
> > Kurzweil



Sun, 03 Apr 2005 14:49:21 GMT  
 sort() causes crash in release mode

Quote:

> No, I think his predicate is ok; it's just a little confusing to read -
> watch the parenthesis...Peronsally, I'd probably write it this way:

> if (v0.x < v1.x) return true; if (v1.x < v0.x) return false;
> if (v0.y < v1.y) return true; if (v1.y < v0.y) return false;
> if (v0.z < v1.z) return true; if (v1.z < v0.z) return false;
> return false;

Here's another possibility:

if (v0.x != v1.x)
        return v0.x < v1.x;
else if (v0.y != v1.y)
        return v0.y < v1.y;
else
        return v0.z < v1.z;

(I HATE writing explicit boolean values when you can get them directly
from conditional expressions <g>)

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)



Sun, 03 Apr 2005 21:16:26 GMT  
 sort() causes crash in release mode

Quote:

> > No, I think his predicate is ok; it's just a little confusing to read -
> > watch the parenthesis...Peronsally, I'd probably write it this way:

> > if (v0.x < v1.x) return true; if (v1.x < v0.x) return false;
> > if (v0.y < v1.y) return true; if (v1.y < v0.y) return false;
> > if (v0.z < v1.z) return true; if (v1.z < v0.z) return false;
> > return false;

> Here's another possibility:

> if (v0.x != v1.x)
> return v0.x < v1.x;
> else if (v0.y != v1.y)
> return v0.y < v1.y;
> else
> return v0.z < v1.z;

> (I HATE writing explicit boolean values when you can get them directly
> from conditional expressions <g>)

Pete,

Since I am in the minority nowadays but still subscribe to single entry/exit
points for each function/routine I thought I'd add:

return((v0.x != v1.x) ? (v0.x < v1.x) :
          (v0.y != v1.y) ? (v0.y < v1.y) :
                                   (v0.z < v1.z));

Loz.



Sun, 03 Apr 2005 21:39:29 GMT  
 sort() causes crash in release mode

Quote:




> > > No, I think his predicate is ok; it's just a little confusing to read -
> > > watch the parenthesis...Peronsally, I'd probably write it this way:

> > > if (v0.x < v1.x) return true; if (v1.x < v0.x) return false;
> > > if (v0.y < v1.y) return true; if (v1.y < v0.y) return false;
> > > if (v0.z < v1.z) return true; if (v1.z < v0.z) return false;
> > > return false;

> > Here's another possibility:

> > if (v0.x != v1.x)
> > return v0.x < v1.x;
> > else if (v0.y != v1.y)
> > return v0.y < v1.y;
> > else
> > return v0.z < v1.z;

> > (I HATE writing explicit boolean values when you can get them directly
> > from conditional expressions <g>)

> Pete,

> Since I am in the minority nowadays but still subscribe to single entry/exit
> points for each function/routine I thought I'd add:

> return((v0.x != v1.x) ? (v0.x < v1.x) :
>           (v0.y != v1.y) ? (v0.y < v1.y) :
>                                    (v0.z < v1.z));

Mine has a single exit point. It's just a bit broader than yours.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)



Sun, 03 Apr 2005 21:50:54 GMT  
 sort() causes crash in release mode

Quote:

> [...]
> Since I am in the minority nowadays but still subscribe to single entry/exit
> points for each function/routine [...]

  With exceptions, what's the point of doing so?

Quote:
> Loz.

  Schobi

--

I'm HSchober at gmx dot de



Mon, 04 Apr 2005 16:17:21 GMT  
 sort() causes crash in release mode

Quote:


> > [...]
> > Since I am in the minority nowadays but still subscribe to single entry/exit
> > points for each function/routine [...]

>   With exceptions, what's the point of doing so?

It makes code easier to understand. That's not changed by the
possibility of throwing exceptions.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)



Mon, 04 Apr 2005 21:04:04 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. DAO:DeleteIndex causes Release mode crash

2. Overwriting pDocTemplate->m_hMenuShared causes crash in Release Mode

3. WM_TIMECHANGE causes crash in release mode

4. WM_TIMECHANGE causes crash in Release mode

5. Program runs fine in debug mode, but crashes in release mode

6. Install DAO with silent mode cause DB application crash

7. Control DDX problem, causing Kernel32 crash only in debug mode

8. CTreectrl/getitemtext causing abend in release mode only

9. ATL component in release mode crashes Win2000 clients

10. ATL component in release mode crashes W2000 clients

11. MFC client crashes in release mode only with ATL composite control

12. Crashes in release mode but not debug

 

 
Powered by phpBB® Forum Software