sort() causes crash in release mode
Author 
Message 
Kurzwei #1 / 25

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 


Igor Tandetni #2 / 25

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 


Ken Alverso #3 / 25

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 


James Curran/MV #4 / 25

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.aurorainc.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 


Larry Brasfiel #5 / 25

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 


Ken Alverso #6 / 25

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 


Pete Becke #7 / 25

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 


Larry Brasfiel #8 / 25

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 


Pete Becke #9 / 25

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 


Kurzwei #10 / 25

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 


Pete Becke #11 / 25

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 


Lawrence Grove #12 / 25

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 


Pete Becke #13 / 25

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 


Hendrik Schobe #14 / 25

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 


Pete Becke #15 / 25

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 


Page 1 of 2

[ 25 post ] 

Go to page:
[1]
[2] 
