Hola a todos:
Hace unos meses que estoy utilizando el Visual C++ 7 ( el .NET ) y me ha gustado bastante... hasta hoy.
Tengo mi programita y tal, que funciona bien EN MODO DEBUG, pero a la que lo paso a Release, no funciona... esto me habia pasado con anteriores versiones, pero realmente era culpa mia ( memory leaks y tal ). He estado toqueteando las opciones de compilacion y he visto donde falla. En la opcion Optimize, si la desactivo, me funciona bien.
Y ahora paso a explicar mi problema :P
El caso es que tengo mi programa que hace cierta cosa ( no creo que sea importante el explicarlo ) y lo hace bien, pero cuando lo paso a Release simplemente se comporta de manera distinta. Es como... si se saltase instrucciones o algo asi... estoy realmente desesperado. Alguien sabe si ya ha salido un Service Pack para esta version del Visual ( la he buscado, pero no la encuentro ).
Muchisimas gracias a todos
Un saludo
mmm, porque crees que falla el VS7 y que necesita un service pack??
No quiero decir que tu programa este mal, sino que mas bien parece el modo release cambia algo que hace que tu programa no funcione bien. No se que puede ser pero me resulta muy extrano. Dices que te parece hay instrucciones que no se ejecutan o algo parecido... cuales son? como es el codigo? de que va el programa? (trabaja mucho con la memoria/ ficheros/ red / que hace)
Hola!
Pienso que falla el VS7 porque estoy un poco agonizado :b, y creo que necesita un Service Pack porque con el VS6 hicieron unos cuantos ;b
Yo soy el primero en pensar que mi programa esta mal, pero le he dado mil vueltas, y el VS7 hace cosas raras.
Las instrucciones que parece que no ejecute son comparaciones de "mayor", "ands" y menor, con coma flotante.
Mi programa es un sistema de camaras. No hay nada raro ni duro sobre trabajo con memoria, archivos, redes ni cosas por el estilo. Es solo una camara, un escenario y un control de teclado. Por eso me extraña.
En fin, si a alguien le ha ocurrido algo asi, que me lo diga, porfavor.
Gracias de nuevo
Yo estoy seguro al 99% de que el fallo debe ser tuyo. Y si dices que en modo debug no va y sí lo hace en release....está claro que se te va la memoria por algun lado...
Yo he estado usando el VC++ 5.0 hasta hace dos meses sin service packs y no encontré ninguna situación en la que pudiese echarle la culpa al compilador. Postea aquí el código y le echamos un vistazo :-D
Yo el otro día me tiré 40 minutos para corregir un bug, y resulta que había construido mal un if-the-else a la hora de poner las llaves...
:-D
Seguro que es un fallo tonto.
Suerte!
Recuerda que en debug te pone las variables a 0 y demás cosillas.
Suena como si el compilador comprobara en tiempo de compilación que el flujo del programa no pasa por las instrucciones que dices que te omite, comprueba los if y demás cosas.
Suerte :!:
Muchisimas gracias a todos : )
Esta misma noche volvere a ello... pero sigue pareciendome extraño... yo tengo la mania de inicializar siempre las variables... ah! Y dije que en DEBUG me va y en RELEASE no ;b
Un saludoteee!!
estoy en la misma situación que MChiz, aunque yo con VC6. Supongo que será fallo mio pero no lo encuentro :
En Debug tira, en Release no (fallo de compilación). Aunque concuerda con lo que dice MChiz de que parece que se salte instrucciones. Hago varios "Log()'s" durante la ejecución, hasta que peta y s0lo se guardan algunos (¿?) cuando en el debug se guardan todos. Estos logs no estan en bucles ni ifs ni nada , cosa rara donde las haya.
Si deshabilito el "optimize", tal como dice MChiz, sí que va :
Una vez tuve un problema de este tipo, pero fué por mi culpa, por hacer cosas raras con las variables. Os cuento mi caso:
Para mi comodidad, creaba 4 variables consecutivas de tipo short:
short var4,var3,var2,var1;
después modificaba estas variables a placer, y luego las cargaba en un registro mmx de golpe:
_asm{
lea edi,var1
movq mm0, qword ptr[edi]
}
En modo debug, funcionaba bien, ya que las 4 variables se creaban de forma consecutiva en memoria, ocupando cada una 2 bytes (lo normal, siendo un short).
La cuestión es que en modo release el programa no funcionaba. Tras muchos quebraderos de cabeza, conseguí averiguar que al activar la optión "optimize for speed" en el modo release, las variables ocupaban 32 bits cada una, imagino que el compilador hace esto para trabajar siempre con registros de 32 bits, lo que resulta más rápido que ir cambiando entre instrucciones de 16 y 32 bits. Por lo tanto, las variables ya no se creaban de forma consecutiva en memoria, y al cargarlas en el registro mmx sólo conseguia cargar 2 de ellas y unos 0000 intercalados...
Sé que este es un problema muy poco corriente, debido a mi chapucera forma de programar aquello, pero igual te puede dar alguna pista...
un saludo
pues no es mi caso, porque yo de manejos de memoria a bajo nivel y cosas de estas no hago xDD
yo pienso lo mismo de grungnor, en debug inicia las variables a 0 ...
por cierto ethernet, de donde puedo pillar la python22_d.lib ? es que no la encuentro y necesito compilar en debug!
no está ahí, se lo tiene que compilar uno, pero ya me lo ha pasado Gar|on :P:P
pues no se donde esta el error, ami nunca me ha dado error.. y siempre compilo en release.
si te da tu codigo memory leaks... debuggealo paso a pasito y sabras onde puede estar el error.
yo siempre compilo con nivel wc4, el maximo.^^
tengo un amigo al k le pasaba una cosa como la tuya pero eso era un despiste suyo... compilaba n debug... y cuando compilaba en release no le iba.. le daba errores de linkeo... pork no habia linkeao las librerias dx en el modo release.. una chorra...
ciertamente, si pegaras los mensajes de error (y warnings si esk tienes ^^), se te podria ayudar.
podriais pegar los mensajes de error... si se dice k tengo un error... averigua onde es...una aguja en un pajar
seguro k es un error ultra tonto.. un despiste.
no creo k por programar una camara k se mueve por un escenario de tantos problemas en modo release.. :-?
pd. uso winxp con el vc++7. y no tengo service packs nuevos.
pd. si tu codigo funciona en debug tiene k ir por webos en release, vamos creo yo, por lo menos ami nunca me ha dao un error.
Citarpodriais pegar los mensajes de error... si se dice k tengo un error... averigua onde es...una aguja en un pajar
son errores en ejecución probablemente como los que me salen a mi: "la memoria en XXXXX no puede ser "read/write" o alguna parida por el estilo.
CitarHago varios "Log()'s" durante la ejecución, hasta que peta y s0lo se guardan algunos (¿?) cuando en el debug se guardan todos. Estos logs no estan en bucles ni ifs ni nada , cosa rara donde las haya.
Asegúrate que guardas la información. Si sólo haces un write() o fprintf() o lo que sea no se te guardará todo porque estará cacheado y al petar el programa no llegará a escribirse al HD.
Puedes utilizar alguna función tipo flush() o también puedes abrir y cerrar el fichero cada vez que escribas algo al HD. Así se te guardará el log hasta el punto en que peta. También apostaría que el fallo es vuestro y no del compilador, aunque eso a veces es duro reconocerlo :X9:
sync
hay un 99,9% de probabilidad de que sea problema nuestro, pero es raro que en vez de petar en un lugar y punto, se vaya saltando cosas.. para cada Log() ya hago fflush() asi que eso no creo que sea :
Pues ya sólo os queda descubrir por qué se las salta (una condición que suponeis que se tendría que cumplir y no se cumple, etc... ^_^)
Si quieres me envías el programa este un dia por la mañana (con el MSN mismo...) y si no tengo mucho trabajo, a lo mejor puedo mirártelo ;)
sync
Pues tengo un problema bastante parecido. En un benchmark que hicimos entre AgeR y yo para un trabajillo de clase (lo posteo más abajo) resulta que con el gcc, en modo de optimización normal no funcionaba (mejor dicho, no hacía lo que tenía que hacer) pero con el modo de optimización -O2 iba perfectamente. Para más detalles, si ponía un printf debajo del switch, no me lo sacaba (ejecutaba el programa y no hacía nada, se quedaba "colgado") pero si ponía otro printf encima del switch, me sacaba ambos printf aunque seguía sin hacerme nada de lo que debería hacer.
Sería un poco largo comentar qué hacía el programa (es un benchmark que tiene tantos hijos como le pases en el segundo parámetro, y cada uno de esos hijos abría un historial con tiempos de procesos de una carpeta y ejecutaba un bucle infinito marcando una X por la salida de error estándar cada vez que acababa de hacer uno de esos "procesos", de forma que había que ejecutarlo como bench numhijos 1>/dev/null 2>fichero_res)
El código:
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
int i,n,t,proc,hijo=0,estado,numproc;
FILE *Historial;
char ASCII[3];
char ControlChar;
char *hist;
proc=0;
numproc=atoi(argv[1]);
while((proc<numproc) && !hijo)
{
if(fork()!=0) /*PROCESO PADRE*/
{
if(proc++ == (numproc-1))
{
wait(&estado);
}
} /*ten mas hijos y espera a que acabe el ultimo*/
else /*PROCESO HIJO*/
{
switch(proc%5)
{ /*Eleccion del historial dependiendo del numero de proceso*/
case 0: sprintf(hist,"tl%d",((proc/5)%15+1));break;
case 1: sprintf(hist,"tm%d",((proc/5)%15+1));break;
case 2: sprintf(hist,"tx%d",((proc/5)%15+1));break;
case 3: sprintf(hist,"tj%d",((proc/5)%15+1));break;
case 4: sprintf(hist,"tv%d",((proc/5)%15+1));break;
default: printf("ARGFASDFn");
};
hijo=1;/*impedimos que el hijo cree mas hijos*/
if (( Historial = fopen(hist, "r")) == NULL)
{
fprintf(stderr, "No se puede abrir el fichero de entrada.n");
}
else
{
printf("archivo abierto y funcionaln");
while(1)
{
do
{
fread(ASCII, sizeof(ASCII), 1,Historial);
t=0;
do
{
n=0;
while(n++<45)
{
i=0;
while(i++<13)
printf("Soy un programa y molo, %d,%dn",n,i);
}
}
while(t++<atoi(ASCII));
fprintf(stderr,"Xn");
fread(&ControlChar, sizeof(ControlChar),1, Historial);
}
while (ControlChar != EOF);
fseek(Historial, SEEK_SET, 0);
}
fclose(Historial);
return 0;
}
}/*FIN DEL PROCESO HIJO*/
} /*FIN DEL WHILE*/
}
Mars, sin abusar XDDD
Por cierto que esto...
i=0;
while(i++<13)
printf("Soy un programa y molo, %d,%dn",n,i);
...con lo poco que cuesta hacer un for() vulgaris.... :loco:
Así a primera vista, un posible error es que si en ASCII[] pones un número de 3 cifras, el último char fijo que no será cero y por tanto el atoi(ASCII) te puede dar cosas alucinantes, además no está inicializado (aunque eso no creo que sea problema)
Si fuera eso, sería probablemente debido a que con -O2, entre ASCII[] y la siguiente variable pone un byte 0 de padding para que las variables estén alineadas a 32bits y en cambio sin optimización no. No sé, tampoco lo he probado, pero es lo primero que se me ocurre ;)
sync
Lo del for es lo de menos, ésa parte sólo sirve de "bulto" para que el programa tarde un poco en hacer "algo". Todos los números del historial tienen tres cifras, así que eso no es problema. Además, esa parte a solas compilaba y funcionaba bien.
Emmm... el problema que yo veo es cuando son de 3 cifras precisamente y ControlChar != 0 (¿no lo ve nadie más esto? ^_^') Pero que no quiere decir que sea el que haga que te funcione mal.
Es que ControlChar sólo está ahí para leer el carácter de fin de fichero para volver a empezar el archivo cuando se haya acabado. Mientras tanto, sólo leerá los n de final de línea. En fin, en cualquier caso, el programa hace lo que tendría que hacer en su versión "desforkada", así que no es la parte que me preocupa. Creo que todo el jaleo viene con el switch, pero yo no le encuentro ningún problema al switch :(