Pregunta de C

Horst von Brand vonbrand en inf.utfsm.cl
Mie Mayo 10 14:00:35 CLT 2006


Alvaro Herrera <alvherre en commandprompt.com> wrote:
> rodrigo ahumada escribió:
> > On Tue, 9 May 2006 20:07:10 -0400
> > Alvaro Herrera <alvherre en alvh.no-ip.org> wrote:
> > 
> > > Se aprecia que las variables arr y nulls son creadas como arreglos del
> > > tamaño especificado que no es constante en tiempo de compilacion, sino
> > > que se determina en tiempo de ejecucion dependiendo del contenido del
> > > struct Relation.
> > > 
> > > Es valido esto?  Debo mencionar que compila perfectamente sin ningun
> > > warning (con varias opciones -W), y que funciona perfectamente para
> > > algunos valores de foo->natts.  Sin embargo, el programa se cae en un
> > > caso muy particular que es cuando foo->natts es 61, un valor superior a
> > > los valores tipicos.  (natts es el numero de columnas de una tabla; por
> > > lo tanto 61 es un valor perfectamente valido pero tipicamente los
> > > valores andan cercanos a la veintena).
> > 
> > [...]
> > 
> > yo hice este codigo:
> > 
> > [...]
> 
> > y al ver el .s que sale:
> >  (lo estuve siguiendo un poco, no se si lo hice bien, pero se nota que
> >  en la funcion rareza, en dos partes se guardan bytes en el stack
> >  segun el valor de [ebp+8] (valor))

> Gracias!  Yo no se leer assembly lamentablemente :-(  Pero creo que tu
> interpretacion tiene sentido, e indica que no hay un bug realmente, sino
> que el codigo deberia funcionar.

Esto es formato intel, de por si mucho mas ilegible que cualquier otra cosa
que se haya inventado. Igual.

[...]

> Segun esto, estaria reservando en el stack tanto espacio como sea
> necesario para guardar el arreglo.

Exacto! Dos veces, y deja punteros a los arreglos resultantes donde
corresponde (para su uso futuro).

[...]

> Ok, tengo que acotar que el problema parece ser que al llegar a un
> cierto tope escribiendo en el arreglo, empieza a escribir en la variable
> que viene despues en el stack.  O sea creo que algo asi deberia mostrar
> el problema -- sin embargo, el programa funciona perfectamente y el
> canario no se muere.

Insisto, si no es el caso que "casualmente" se sale del rango puede ser
compilador funado; o esta sobreescribiendo esa variable desde otro lado.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513


Más información sobre la lista de distribución Linux