[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#8685) Invalid memory access



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?