Problemas Recompilando En Diferentes Distros

[LC0]

 No se si catalogar esto como una cuestión de programación o de parapsicología, pero bueno, ahí va:

A principios de año estuve terminando de realizar mi PFC bajo una Kubuntu, en su versión para amd64, usando C++, Flex, Bison, y la biblioteca wxWidgets, fundamentalmente (también alguna que otra extensión GNU a las bibliotecas estándar).

Ahora tengo una Fedora Core 4 para x86, que es la que mejor va en mi portátil (amén de ser en la única donde he podido instalar los drivers para la ATI bien), y, por cuestiones de la vida, necesito otra vez el proyecto para presentarlo en unas jornadas.

Tras meter todas las bibliotecas necesarias, recompilo, y todo parece funcionar a la perfección. Pero nada más lejos de la realidad.

El bicho en cuestión es un intérprete de diagramas de flujo, que los compila a código de una máquina virtual interna, y los ejecuta y depura. El problema está en que, en la Kubuntu, todos los diagramas que vienen incorporados como ejemplos funcionan a la perfección, pero en la Fedora, la compilación de algunos hace que la aplicación lance un "segmentation fault".

Descartando potenciales sospechosos:

-No tiene que ver nada con el paso de un sistema de 64 bits a uno de 32: La aplicación la he testeado en otra Kubuntu de la misma versión que tenía antes en el portátil (Breezy) para x86, y no da este problema. Además, he tenido especial cuidado de no usar tipos de datos que abarquen 8 bytes (el wxWidgets trae tipos como wxInt32, wxInt8, etc.)

-Tampoco tiene que ver con diferencias entre versiones instaladas. Viendo los changelogs oportunos, nada indica que sea el caso.

Intenté compilar el binario enlazando estáticamente las librerias, pero me fué imposible por varios problemas que no son el caso (además, si el bicho está liberado como GPL, todo el mundo debería poder compilarlo sin efectos raros :D).

Así que, nada, tocó depurar. No usé el gdb porque contiene código "raro" (niños, jamás depureis código generado por Bison/Flex xDD), así que tocó usar el típico método de los mensajes estilo "hasta aquí llego".

Ahora viene lo gracioso. Insertando e insertando estas líneas, acabé llegando donde podría estar localizado el problema. Pero, la colocación de una de estas ha servido de solución. Es decir, un std::cout ha hecho que la aplicación deje de salirse abruptamente :ph34r:.

En concreto, el cacho código es este:

Código [Seleccionar] Expand


       //...
else if(Pos >= 0 && NodeMemoryPos.at(Pos) < 0)
{
 NodeMemoryPos.at(Pos) =  vm.getMemorySize();
 n->translate(vm);
               std::cout << "N DE HIJOS: " << n->getNumChildren() << std::endl; //<--Mi héroe particular
 if(n->getNumChildren() == 2)
 {
  Instr.Func = jnz_ax;
  vm.putMemoryCell(Instr);
  InstrPos = vm.getMemorySize() - 1;
 }
              //...
      }
      //...


Se me han venido a la cabeza varias teorías de por qué podría estar ocurriendo esto, pero las encuentro tan absurdas que prefiero callármelas (ya sabeis, es mejor estar callado y parecer tonto que abrir la boca y demostrarlo xD).

¿A alguien le ha pasado algo por el estilo? ¿Alguien sabría decir que podría estar ocurriendo?

De antemano, muchísimas gracias, y sobretodo, por haber leido hasta aquí :).

EDIT: Perdón por la identación, que parece que se ve un tanto amorfa...

[TheAzazel]

 Ese problema huele a punteros....
en algun sitio liberas algo, o en algun sitio accedes a algo... vamos, que telita tela. Por eso poner el cout, modificas el codigo y por suerte, no te casca pero a saber que te esta haciendo por ahi....

y amigo, esos errores son un poco desesperantes, intenta utilizar algun sistema debug que controle el numero de veces que reservas y liberas memoria(hay muchos en la red que simplemente sobrecargan el new y el delete) y si tienes suerte, lo pillaras rapido...


a mi eso me ha pasado alguna que otra vez y con mayor o menor tiempo, acabas cazandolo, un sistema que aprendi a usar es siempre inicializar el puntero a NULL, y antes de liberar, comprobar que es distinto de NULL, acto seguido, hacerlo valer tambien NULL, con esto, te quitas muchisimos problemas, ademas, es bueno agregar un log para saber donde estas intentando liberar algo que o ya fue liberado o nunca fue reservado y asi tener un codigo mucho mas limpio y estable :)

animo!

[vincent]

 Coincido con The Azazel. Esto huele a punteros que no veas.

Yo alguna vez he utilizado el memory manager de esta gente ( FluidStudios ) y me ha ido bastante bien.

Suerte!!

[feclare]

 Te recomiendo que pruebes a ejecutarlo con valgrind. Es una gran ayuda para depurar punteros y accesos descontrolados a memoria. En kubuntu tienes paquetes, supongo que en fedora tambien.

Suerte

[LC0]

 Bueno, paquetes del Valgrind no he encontrado para la Fedora, pero bueno, lo he instalado desde las fuentes.
La verdad es que me ha pillado unos cuantos memory leaks, ahora habría que analizar más a fondo que función los provoca.

De todas formas, me resulta raro el hecho de que la zona de código problemática no hace ninguna reserva de memoria.

Gracias again!

[TheAzazel]

 

De todas formas, me resulta raro el hecho de que la zona de código problemática no hace ninguna reserva de memoria.

Eso no importa, de lo que se trata es que quizas algun puntero esta pisando el codigo justo donde te peta, vamos que el error lo provoca ahi pero puede venir de cualquier sitio. Al poner el cout lo unico que haces es agregar mas codigo y puede que pises codigo del cout y algo no funcione como debiera pero continua... pero vamos, que estos errores son los peores porque el resultado es casi aleatorio, no siempre tiene que suceder lo mismo, dependen del codigo generado, etc. pero vamos, que algo malo esta por ahi, que no te casque a la primera no significa nada, te puede cascar despues, o a los 30min...


No conocia el manager ese....lo probare esta tarde a ver que tal, si me pilla alguno que no haya cogido con mi pequeno codigo, descarto el mio y utilizo este :P

armate de paciencia y animo!