[XviD-devel] [BUGS] failure on alpha processor and memory leakings

[Christoph Lampert]

On Fri, 21 Feb 2003, Edouard Gomez wrote:
> Program received signal SIGSEGV, Segmentation fault. 
> 0x120031f28 in sad16_c (cur=0x2000037d690 "...",
>                         ref=0x201003a94b0 <Address 0x201003a94b0 out of bounds>, 
>                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>                         stride=480, best_sad=1048576) at ../../src/motion/sad.c:68


Most likely again a "pointer are 64bit but offset calculation is done in
32bit" problem. E.g. I guess "stride" values should always be of type
ptr_t instead of int32_t and especially they should not be of type
uint32_t. 

> Is the code 64bit ready ? Could you  have a look at your code and try to
> find code areas where 64bit could lead to problems ? 

Is it better for 64bit to use   
&cur[x*stride+y] notation instead of cur+x*stride+y ?   
Does (cur + x) work when x ist signed int32_t with negative value
and cur is a pointer? 

Then we could go through the code once and for all and remove all
unnecessary "int32_t/uint32_t" and also make everything signed that is
needed. Actually make everything signed which is used for calculations
and where extra bit is not needed (e.g. macroblock x-dim etc, too). 


> @all
> 
> When i  saw the  alpha regression, I  decided to  see if this  error was
> present in  the ia32 arch  but for some  obscure reason did  not trigger
> SIGSEGV signal (it's common that libc on ia32 allocates a bit more space
> than needed, thus allows implicitly out of bounds operations)

In sad16_c as well? That's strange... 
 
> And we have  two memory leaks in  core. Not sure whether the  leak is in
> core or xvid_encraw. I'll have a look tomorrow but if you have time then
> "many eyes" are always better than mine(+glasses) only. 
> 
> You have the valgrind report in attachement.

I don't think it's xvid_encraw. That allocated only two buffers,
but both are freed in the end unless the program terminates early. 
The buffers are of the size  XDIM*YDIM*3/2 resp. XDIM*YDIM*3 
so one is twice the size of the other and the valgrind output seems to
have different sizes. Is seems one is 5 times the other two, and the rest
might be due to ALIGNMENT. 


@all: Just as a general information:  Calling free(NULL) is completely
legal ANSI C, it does exactly nothing. So checking for ptr!=NULL is never
needed before free'ing. Often code gets a little more readable by not
checking.

gruel