Re: [Boost-bugs] [Boost C++ Libraries] #5143: segfaults in ordered_index

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #5143: segfaults in ordered_index
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2011-01-31 11:25:04

#5143: segfaults in ordered_index
---------------------------------------+------------------------------------
  Reporter:  christoph.kluge@…         |       Owner:  joaquin    
      Type:  Bugs                      |      Status:  closed     
 Milestone:  To Be Determined          |   Component:  multi_index
   Version:  Boost 1.35.0              |    Severity:  Problem    
Resolution:  invalid                   |    Keywords:             
---------------------------------------+------------------------------------
Changes (by joaquin):

  * status:  new => closed
  * resolution:  => invalid

Comment:

 ''What, if x->left() becomes 0?''

 If x->left() is 0, then x=x->left() is not executed and x retains a non-
 null value (specifically, x points to a node whose left child is 0).

 ''Well, it does, over here! ''

 Can you provide a complete test program showing the effect? Without any
 other info, my bet is the internal rb-tree has been corrupted by some bug
 in your program.

 ''Shouldn't this read

     while(x!=pointer(0)&&x->left()!=pointer(0))x=x->left();''

 No; note that just before the while loop we have

     if(x->right()!=pointer(0)){
       x=x->right(); ...

 So x can't be null and the extra check inside the loop is redundant.

 ''What is this line of code supposed to do anyway, other than uselessly
 consuming CPU time? Why not write''

     x = 0;

 As explained above, x won't be null after executing the while loop.

 ''ordered_index_node_impl_base::left and
 ordered_index_node_impl_base::right do not have any side-effects.''

 This is supposedly not related to your problem, but: what's the problem
 with those member functions not having side effects?

 ''By the way, for the classes ordered_index_node_std_base and
 ordered_index_node_compressed_base, I don't see any of the POD data
 members getting initialized. A user-provided constructor is not defined.
 From the C++ Standard, IIRC, POD data members are not initialized by the
 implicitly-generated constructor and therefore have indeterminate
 values.''

 This is correct. Initialization takes place at points in time other than
 construction, for instance in ordered_index::empty_initialize() and
 ordered_index_node_impl::link(). It is not an error to let POD values be
 uninitialized as long as they are actually initialized before being read.

 ''To me this looks like this is working only by chance. Has anyone ever
 bothered to review this code?''

 This is slightly offensive but, as it does not contain either info on your
 problem or any other useful suggestion, I'll just ignore it.

 I'm closing this as "invalid" (i.e. no bug detected). If you can come up
 with a test program where the crash happens please reopen the ticket and
 attach the relevant info. Thank you!

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/5143#comment:1>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.