🚀 go-pugleaf

>>>>> "Luis" == Luis Molina <lmolina@redestb.es> writes:

    Luis> Hola!  Tengo un problema muy extra�o ahora que me actualic�
    Luis> de la Debian 2.0 a la Debian 2.1 (aunque no esoty seguro de
    Luis> que se deba a ese cambio).

    Luis> Estoy este verano haciendo un programa en C++ (para una
    Luis> asignatura) bajo Linux, y sucede que en cierto m�todo de una
    Luis> clase al intentar reservar memoria devuelve el no deseable
    Luis> mensaje de que ha recibido una se�al SIGSEGV (la forma
    Luis> elegante del Segmentation Fault).

Por lo que cuentas, y diciendo que lo hace a la tercera, me da en la
nariz que estas pisando memoria que no es tuya. Me explico, malloc no
solo reserva la memoria que tu le pides, sino un poco mas para la
informacion de control suya. Este trozo adicional suele ser contiguo a
la memoria reservada para ti. Si tu te sales de tu zona y tocas en la
suya, en las siguientes invocaciones sueles tener problemas como el
que describes.

Asi que revisa bien el uso que haces de la memoria reservada en ese
metodo. Como ultimo recurso puedes usar comprobadores como Electric
Fence o Checker que sirven para detectar este tipo de problemas.
Saludos. I�aki.

-- 
  PGP Key available at http://personales.jet.es/inaki.arenaza/pgpkey.html
  Linux Registered User #44369

Hola!

Ignacio Arenaza wrote:

>     Luis> Estoy este verano haciendo un programa en C++ (para una
>     Luis> asignatura) bajo Linux, y sucede que en cierto m�todo de una
>     Luis> clase al intentar reservar memoria devuelve el no deseable
>     Luis> mensaje de que ha recibido una se�al SIGSEGV (la forma
>     Luis> elegante del Segmentation Fault).

 
> Por lo que cuentas, y diciendo que lo hace a la tercera, me da en la
> nariz que estas pisando memoria que no es tuya. Me explico, malloc no
> solo reserva la memoria que tu le pides, sino un poco mas para la
> informacion de control suya. Este trozo adicional suele ser contiguo a
> la memoria reservada para ti. Si tu te sales de tu zona y tocas en la
> suya, en las siguientes invocaciones sueles tener problemas como el
> que describes.

Puede ser, mirar� despacito el uso de la memoria, gracias, si es eso ya
lo dir�.

-- 
            L U I S  M O L I N A     :)    "We're happy as fish, and
            --------------------------------------------------------
            gorgeous as geese, and wonderfully clean in the morning"
  
            <http://personal.redestb.es/lmolina> Bledo en la Red
            <http://personal.redestb.es/lmolina/genesis.htm> Genesis

A 22 Jul 1999 16:52:33 +0200, Ignacio Arenaza <inaki.arenaza@jet.es>
escribiste:

>>>>>> "Luis" == Luis Molina <lmolina@redestb.es> writes:
>
>    Luis> Estoy este verano haciendo un programa en C++ (para una
>    Luis> asignatura) bajo Linux, y sucede que en cierto m�todo de una
>    Luis> clase al intentar reservar memoria devuelve el no deseable
>    Luis> mensaje de que ha recibido una se�al SIGSEGV (la forma
>    Luis> elegante del Segmentation Fault).
>Por lo que cuentas, y diciendo que lo hace a la tercera, me da en la
>nariz que estas pisando memoria que no es tuya.
Pos hombre, si hay un segmentation fault, est� bastante claro que es
porque pisas memoria de otro. De todas formas, estoy hasta el qlo de
SISEGVs cuando kompilo el kernel. Linux no funciona en mi ordenata ni
a tiros. Se cuelga al de un rato de arrancar etc. y siempre SISGEVs de
esos por medio. � ser� la RAM ?
> Me explico, malloc no
>solo reserva la memoria que tu le pides, sino un poco mas para la
>informacion de control suya. Este trozo adicional suele ser contiguo a
>la memoria reservada para ti. Si tu te sales de tu zona y tocas en la
>suya, en las siguientes invocaciones sueles tener problemas como el
>que describes.
Pos hombre, eso es mu bonito. Pero entonces significar�a que malloc
tiene un fallo mun gordo. Se supone que busca una zona de memoria
libre y � se pisa a si mismo ? Lo cierto es que llevo exactamente 8
d�as "programando" C, pero no me pega nada que eso pueda ser as�. De
lo contrario, � cu�ntas variables din�micas puedes declarar ? 2 ? Las
declaras todas al principio ?
Creo que no.
De todas formas, si que he visto algo en el mensaje de Luis Molina que
me ha llamado mucho la atenci�n. Repito que llevo __ocho__ d�as en
esto del "C" y "C++", pero si mal no recuerdo, en el libro de Fco.
Javier Ceballos -que me le� en dos d�as, con lo que puede que me
equivoque- dec�a que malloc y new son incompatibles y que s�lo se
puede utilizar una de ellas en los programas, por la forma que tienen
de reservar la memoria. Por lo que recuerdo -supongo que mal, pero
bueno- malloc reserva la memoria desde la cima del c�digo hacia la
pila y new desde la pila hacia la cima del c�digo. Quiz� es por eso,
que se pisan los news con los controles de los mallocs ... �? no lo
s�. En fin, espero no haberos vuelto locos y al menos, haberos dado
alguna idea �til.

Cymoril sin patas
03:12 a.m.



-----------------------------------------------
Cymoril sin patas

"I believe this is heaven to no one else but me, and I'll defend it as long as I can be left alone to linger in my own silence." 

-----------------------------------------------

Como bien dice Cymoril, mezclar malloc y new en C++ es un problema. En todos
sitios se recomienda new. Parece que es m�s potente y seguro.

No uses malloc con C++. new es mejor.

Hola!

Cymoril sin patas wrote:

Bueno, lo solucion�, efectivamente era que ten�a un puntero "perdido" 
que implicaba que el siguiente malloc realizado tras un uso 
"incorrecto" diese ese error.

> >Si tu te sales de tu zona y tocas en la
> >suya, en las siguientes invocaciones sueles tener problemas como el
> >que describes.

> Pos hombre, eso es mu bonito. Pero entonces significar�a que malloc
> tiene un fallo mun gordo. Se supone que busca una zona de memoria
> libre y � se pisa a si mismo ? Lo cierto es que llevo exactamente 8
> d�as "programando" C, pero no me pega nada que eso pueda ser as�. De
> lo contrario, � cu�ntas variables din�micas puedes declarar ? 2 ? Las
> declaras todas al principio ?
> Creo que no.

Pues s� se produce, aunque sigo pensando que es un poco raro, ya que el 
puntero simplemente acced�a a donde no deb�a (y modificar�a datos
referentes 
a esa informaci�n adicional que imposibilitar�a realizar otra reserva de
forma
correcta). Aunque al menos este detalle me ha permitido detectarlo
realizando 
peticiones de memoria en posiciones determinadas del programa ;-).

> Quiz� es por eso,
> que se pisan los news con los controles de los mallocs ... ?

Debido a que en Linux la zona de Heap no est� limitada en Linux este
problema
no se da, por lo que no creo que sea eso. 

>  no lo
> s�. En fin, espero no haberos vuelto locos y al menos, haberos dado
> alguna idea �til.

S�, no sab�a lo de la diferencia de reserva (aunque supongo que ser� m�s
bien un
tema de implementaci�n).

Hola!

Enrique Ferrero wrote:
 
> Como bien dice Cymoril, mezclar malloc y new en C++ es un problema. En todos
> sitios se recomienda new. Parece que es m�s potente y seguro.
> 
> No uses malloc con C++. new es mejor.

Ya, pero es la maldita costumbre por empezar a programar en C.

Luis Molina escribi� en mensaje <379EE6C4.A48E9CD2@redestb.es>...
>Hola!
>
>Enrique Ferrero wrote:
>
>> Como bien dice Cymoril, mezclar malloc y new en C++ es un problema. En
todos
>> sitios se recomienda new. Parece que es m�s potente y seguro.
>>
>> No uses malloc con C++. new es mejor.
>
>Ya, pero es la maldita costumbre por empezar a programar en C.
>

De todas maneras, nadie te ha dicho lo que todos sabemos, que lo mejor para
estos problemas de memoria,
son los �� RABOS DE PASAS !!


X-D


Un saludote.

Un saludo!

Me he perdido el comienzo del hilo (esto de tabajar no deja tiempo para
casi nada :-( ), as� que igual lo que digo no viene a cuento, pero lo
digo por si acaso.

new y malloc hacen una gesti�n diferente y por separado de la memoria,
con lo cual no es imposible que una llamada malloc pise a una new o
viceversa. Lo de que un malloc se pise a s� mismo... no creo.

Aaaaaaaaaagur.

Luis Molina escribi�:
> 
> Hola!
> 
> Enrique Ferrero wrote:
> 
> > Como bien dice Cymoril, mezclar malloc y new en C++ es un problema. En todos
> > sitios se recomienda new. Parece que es m�s potente y seguro.
> >
> > No uses malloc con C++. new es mejor.
> 
> Ya, pero es la maldita costumbre por empezar a programar en C.

-- 
Joseba G. Torre Segarra
(Para responder, quitar a los PESADOS)
Usuario Linux 93245	M�quina... en casa :o(

Hola!

Joseba wrote:
 
> Un saludo!
> 
> Me he perdido el comienzo del hilo (esto de tabajar no deja tiempo para
> casi nada :-( ), as� que igual lo que digo no viene a cuento, pero lo
> digo por si acaso.

No te preocupes, pasa muy a menudo, as� te puedo responder con lo que
creo
que fu� la conclusi�n l�gica (ya lo he solucionado).
 
> new y malloc hacen una gesti�n diferente y por separado de la memoria,
> con lo cual no es imposible que una llamada malloc pise a una new o
> viceversa. 

Eso s� es cierto.

> Lo de que un malloc se pise a s� mismo... no creo.
 
No es que se pisase a s� mismo, sino que un puntero descontrolado al
sobrescribir zonas de memoria no adecuada (pero dentro de la memoria
del programa) en el que se almacenaba informaci�n importante sobre la
memoria utilizada hac�a que al intentar reservar memoria despu�s con
un malloc fallase inevitablemente, as� que ya sabes, si da un
Segmentation Fault al realizar un malloc estudia los punteros que
utilizas.

Hombre, el malloc() i el new son muy diferentes entre si, pero eso no
quiere decir que no se puedan utilizar a la vez en el mismo programa, yo lo
hago sin problemas.

Hay que pensar que el malloc() solo reserva memoria, mientras que el new lo
que hace es crear (o instanciar) objetos. Por supuesto para crear un objeto
el new reserva tambien memoria, pero guarda tambien en ella toda la
informacion necesaria para tratar el objeto.

Lo que no se puede hacer es reservar memoria con malloc() i liberarla con
delete, o al reves, crear objetos con new i liberarlos con fre(). Hay que
tener muy claro cuando se reserva con new i cuando con malloc() para luego
liberar en consecuencia.

Esto no es valido:

	char *p;
	p = malloc(10);
	delete p;

I esto tampoco:
	char *p;
	p = new char[10];
	free(p);

El echo de que no sea valido no significa que no compile. De echo no hay
ningun problema al compilar esto. Se esta trabajando siempre con punteros a
char*.
Pero si se hacen las cosas asi, probablemente, en algun momento aparecera
un error de Segmentation Fault. I ya se sabe, luego encuentralo...

---------------------
Ricard
slump@apdo.com

>new y malloc hacen una gesti�n diferente y por separado de la memoria,
>con lo cual no es imposible que una llamada malloc pise a una new o
>viceversa. Lo de que un malloc se pise a s� mismo... no creo.
	Segun creo recordar lei en "C++ manual de referencia" de Herbert
Shildt que el estandar decia que no se aseguraba la compatibilidad
entre ambos, es decir, que no se pedia pedir memoria con new y
liberarla con el free o pedirla con el malloc y usar el delete para
liberarla, porque aunque en algunas implementaciones funcione, todas
aquellas en las que el new se implementa con malloc, podia no hacerlo.
Y si lo piensas bien, si todo el codigo C usa malloc, calloc, realloc
y free ya no podrias usarlo en C++ donde las la mayor parte de clases
estan plagaditas de new. Ahora razonando podemos llegar a esta
conclusi�n por reduccion al absurdo, si metes algun trozo de codigo en
C puro en un programa en C++ (Se supone que debe funcionar o almenos a
mi siempre me ha funcionado si estaba bien hecho) ya no podrias usar
en ninguna ocasi�n new con lo cual, si 90% del codigo en C que tienes
usa malloc y el 90% del codigo en C++ que tienes usa new, solo podrias
usar un 10% de alguno de los dos juntos. Por lo menos para mi llamar a
esto compatibilidad es absurdo.

	Por otro lado siempre puedes redefinir new para que use malloc, lo
cual puedes encontrar en el libro al que he hecho referencia.

	Tambien discrepo con lo que escribio Enrique Ferrero

>> No uses malloc con C++. new es mejor.

	El C++Builder 1.0 usa malloc para new con lo cual solo es de mas
alto nivel no mejor, desconozco como funcionan otros compiladores pero
supongo que si ya tienen un codigo cojonudo para el malloc para que
inventarse otra jugada, usan la misma abstrallendo al programador. El
dia que me digas como se hace un realloc con new y delete, haciendo un
exceso te dare dos besos, uno por mejilla. Hasta entonces, no podras
convencerme de que es mejor, solo mas facil.

Si me equivoco agradeceria que corrigiesis mi error.

Arrepentiros ahora, Gates es el AntiCristo, recitemos
juntos del libro de C de los profetas Kernigan y Ritchie
capitulo 7 versiculo 8.5 : Las funciones malloc y calloc .....
franci72@iname.es (es=>com)
http://members.xoom.com/franci72
P.D. Pa cal� �cija
P.P.D. Pa linux Debian

>>>>> "franci72" == franci72  <franci72@iname.es> writes:

    franci72> no se podia pedir memoria con new y liberarla con el
    franci72> free o pedirla con el malloc y usar el delete para
    franci72> liberarla, porque aunque en algunas implementaciones...

Esto es lo que dice Schildt y me parece correcto...

    franci72> con malloc, podia no hacerlo.  Y si lo piensas bien, si
    franci72> todo el codigo C usa malloc, calloc, realloc y free ya
    franci72> no podrias usarlo en C++ donde las la mayor parte de
    franci72> clases estan plagaditas de new. Ahora razonando podemos
    franci72> llegar a esta conclusi�n por reduccion al absurdo, si
    franci72> metes algun trozo de codigo en C puro en un programa en
    franci72> C++ (Se supone que debe funcionar o almenos a mi siempre
    franci72> me ha funcionado si estaba bien hecho) ya no podrias
    franci72> usar en ninguna ocasi�n new con lo cual, si 90% del
    franci72> codigo en C que tienes usa malloc y el 90% del codigo en
    franci72> C++ que tienes usa new, solo podrias usar un 10% de
    franci72> alguno de los dos juntos. Por lo menos para mi llamar a
    franci72> esto compatibilidad es absurdo.

Aqui te equivocas de medio a medio. Se puede mezclar malloc y new en
un programa en C++. Lo que no se puede es mezclar malloc con delete o
new con free. Es decir, si reservas con malloc tienes que liberar con
free (y no puedes hacerlo con delete), y si reservas con new tienes
que liberar con delete (y no con free). Esta es la unica restriccion y
lo que dice Schildt segun tu (ver mas arriba). Si respetas esto, tu
"compatibilidad" es del 100%.

De hecho, si lo que tu dices es cierto casi ningun programa hecho en
C++ podria funcionar en Unix/Linux. Porque todos ellos, antes o
despues, usan la libc, que esta hecha 100% en C y usa malloc por todos
los lados ;-)


    franci72> Si me equivoco agradeceria que corrigiesis mi error.

Hecho!! ;-)

Saludos. I�aki.

-- 
  PGP Key available at http://personales.jet.es/inaki.arenaza/pgpkey.html
  Linux Registered User #44369