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