Hey Adrian,
On Thu, Jul 06, 2017 at 10:44:21PM +0200, John Paul Adrian Glaubitz wrote:
> Hi Breno!
>
> On 07/06/2017 09:31 PM, Breno Leitao wrote:
> > I think I found the real case of the problem here. There is an array
> > being allocated, and initialized until 'i'.
> >
> > Later, we use a random number 'r' to access this array, and it will fail
> > if 'r' is bigger than 'i', since any value bigger than 'i' will not be
> > initialized. It might fail harder if 'r' is being allocated than 'nvalues',
> > but
> > I didn't get this scenario during my debugs.
>
> Interesting bug. I wonder how this bug is only triggering on ppc*. Is that
> code that is run on these targets only?
In fact, doing further debugs I understand that the problem is somewhere
else, and what I am seeing is just a consequence of a prior error that was not
prior handled. This is the test case:
for ( i = 0, e = ldap_first_entry( ld, res ); e != NULL; i++, e =
ldap_next_entry( ld, e ) )
{
values[ i ] = ldap_get_dn( ld, e );
}
values[ i ] = NULL;
...
for ( i = 0; i < innerloop; i++ ) {
int r = ((double)nvalues)*rand()/(RAND_MAX + 1.0);
do_read( ld, values[ r ],
srchattrs, noattrs, nobind, 1, maxretries,
delay, force, chaserefs, idx );
}
In ppc64el case, ldap_first_entry() is returning NULL, thus values[], other
than values[0], but the code will contain garbage and we will interate over it
later.
That said, I understand that there are two bugs:
1) we shouldn't iterate over values[] if it is bogus.
2) ldap_first_entry() shouldn't return NULL (real problem)
So, answering your question. My patch *didn't* fix the real issue (2), but the
consequence of it. That explains why we do not see this on other systems.
Anyway, I am still investigating the real problem here, and Howard, from
OpenLdap, is kindly helping.
