Hi Breno,

Thanks a lot for taking the time to look at this.

I reproduced the crash on a minicloud VM (thanks!) with gcc -O2 (but not -O1 or -O0) and also with clang -O2 and -O1 (but not -O0).

On Fri, Jul 07, 2017 at 12:57:47AM +0000, leitao@debian.org wrote:

So, that is what I suppose is happening. On the following loop, ldap_first_entry() is returning NULL, thus, i = 0;

  for ( i = 0, e = ldap_first_entxury( ld, res ); e != NULL; i++, e = ldap_next_entry( ld, e ) )
  {
        values[ i ] = ldap_get_dn( ld, e );
  }
  values[ i ] = NULL;

Thus, value[0] = NULL;

I have not been able to reproduce that. I added an assert(i == nvalues) here, but it never failed in the time I spent on this today.

On IRC, Howard pointed at the computation of 'r' (line 682), and indeed some printf debugging suggests that may be going wrong. I occasionally saw values of 'r' greater than 'nvalues', leading to reads past the end of the array like you suggested.

for example:

nvalues = 19 [...] i=20 r=11 values[r]=0x10014fba0f0 i=48 r=6 values[r]=0x3fff40000bd0 i=49 r=3 values[r]=0x3fff40000b50 i=51 r=7 values[r]=0x3fff6c001310 i=46 r=11 values[r]=0x3fff0c003530 i=56 r=27 values[r]=0x25 Segmentation fault (core dumped)

Unpacking the computation, it looks like the multiplication is the part that sometimes returns the wrong result. For example:

nvalues = 19 [...] rand() -> 745824322 ((double)19)*745824322 -> 45495283642.000000 45495283642.000000 / 2147483648.000000 -> 21.185392 i=75 r=21 values[r]=0x35 Segmentation fault (core dumped)

but 19.0*745824322 should be 14170662118.

I'm not really sure where to look next. Compiler bug would be a nice explanation, but wouldn't it be unusual for gcc and clang to have the same bug?