Buenaaaaaaaaaaaas.
Tras la ardua tarea de realizar mi segundo programita. Mi cabecita loca se ha dado cuenta que todavíiiiiiia estoy muuuuuy verde.
A ver:
Se me estravían los punteros.
Intento acceder a elementos de un array fuera de rango.
Mando signals a procesos que no existen.
El primer caso es relativamente fácil de localizar. Bennu peta bastante rápido.
El segundo ya es más peliagudo. Bennu se vuelve inestable rápidamente y peta.
Y el tercero, bufff, el tercero me vuelve loco.
Bennu se vuelve inestable lentamente y peta al rato. Me cuesta horrores encontrar este último fallo.
Y a lo que íbamos:
¿Algún consejo ayudita? Please.
Graciiiiiiiiiiiiiaaaaaaaaaaaaaas.
deberias tener controlados los punteros, lo mismo te va a pasar en cualquier lenguaje que use punteros.
¿Y como se controla un puntero aparte de no teniendo fallos a la hora de usarlo? ;D
Gracias.
por lo menos sabes usar punteros y signals...
espera, signal para matar procesos, se usar ''signales'' je jej e
por lo menos sabes usar punteros; si tu estas verde yo estoy amarillo, je je
A ver, si se te extravía el puntero, mal vamos, es un fallo gordo del SO, porque entonces el ratón... ;D
Vaaale.
Pues tal como lo planteas, los problemas que me dan a mi esas tres cosas tienen una importancia inversa.
Es decir, el mandar signals a procesos inexistentes da problemas de inestabilidad, pero se soluciona rápidamente con un EXISTS y una rama ELSE que mande un mensaje a la consola. Detectar el problema ya es más complejo, depende de cómo tengas organizado el árbol de procesos y quién lance señales a quien (yo siempre intento que se manden señales en vertical, padre-hijo, o en horizontal, hermanos o procesos del mismo nivel, con menos de dos procesos de diferencia).
Acceder a elementos fuera de rango también se puede controlar mirando los SAY, pero bien es cierto que si no intuyes dónde falla, es difícil localizarlo. La forma más fácil de detectarlo es probar en diversos SO, porque allí donde uno no tiene control (se lo traga, y funciona, aunque se desestabiliza), otro sólo es permisivo (no da error, pero no lee más allá de la zona reservada, y da error la mitad de las veces), y otro lo controla bien (a la mínima, error o segmentation fault).
Y lo de perder el puntero ya sí que no tiene solución. Con un poco de suerte da un error y casca, pero si pierdes el índice, no sabes si lees la dirección o el contenido, o los valores no son correctos, mal vamos. Para esto lo mejor es volver a "pre-escolar" y hacer unos cuantos ejercicios básicos con punteros para "reciclarse". Mano de santo, oiga (te lo dice uno que ha repasado las bases con otro lenguaje).
me refiero a los típicos ejercicios de listas enlazadas, añadir nodos y (muy importante) imprimir datos, porque muchas veces damos por sentado que los datos se guardan y se leen correctamente, pero conviene hacer esta función aunque no se vaya a usar en el programa final, porque es una forma perfecta para depurar errores.
Por lo demás, ya te pediré consejos, porque tu último programa puede tener código que me interese (para empezar, necesito crear la típica ventana de "abrir/guardar archivo" ;D).
Gracias por los consejos.
Y lo de pedirmelos a mí. Jua, jua, tu estás muy mal.
Lo que quieras, pero después no me pegues. ;D
QuoteMando signals a procesos que no existen.
Muy fácil, cambia:
signal ( xxx, S_KILL);
Por:
IF ( exists ( xxx ) )
signal ( xxx , S_KILL );
END
Semen de orco
Me lo suponia, pero mi mente se negama a que fuera tan fácil. ;D
Gracias.
¿Que leches es eso de semen de Orco? Suena a guarrerida.
Es una dll nueva, mod_semen xD
Signal puede dar problemas ? Nunca he notado nada al respecto.
Los type proceso desde luego que son seguros, los ID a saber si se reutilizan a lo largo de la ejecución y te cargas cualquier otro proceso.., quizas el problema es si algun proceso accede al padre y matas primero al padre en el orden de signal, eso si que produce un crash inmediato.
Por mi experiencia, cuando activas un signal a un proceso inexistente, suele responder otro proceso aleatoriamente. Aunque creo que esa aleatoriedad sería más bien por orden de creación.
Aunque también pude ser mi imaginación. :D
Quote from: Fede on March 30, 2011, 06:37:46 PM
Por mi experiencia, cuando activas un signal a un proceso inexistente, suele responder otro proceso aleatoriamente. Aunque creo que esa aleatoriedad sería más bien por orden de creación.
Aunque también pude ser mi imaginación. :D
en bennugd eso es imposible, si el proceso no se encuentra no se manda la señal, pero si mandas una señal a 0, es algo diferente, ya que 0 = all_process, o si mandas un signal a un id menor a 65536, con lo que significa que le estas mandando una signal a un tipo de proceso.
los ids de proceso < a 65536 son tipos de procesos
los ids de proceso >= 65536 y <= 131071, son ids de procesos
el id 0 significa TODOS LOS PROCESOS.
el resto de los valores no se usan.
si una operacion se quiere hacer sobre un id inexistente, dicha operacion no se efectua, esto no aplica a accesos a variables de procesos inexistentes, que provocan un error critico.
Gracias Splinter. Sabía que aparecerías a resolver mis dudas. :D
Quote from: BoMbErLiNk on March 30, 2011, 12:45:06 PM
Signal puede dar problemas ? Nunca he notado nada al respecto.
Los type proceso desde luego que son seguros, los ID a saber si se reutilizan a lo largo de la ejecución y te cargas cualquier otro proceso.., quizas el problema es si algun proceso accede al padre y matas primero al padre en el orden de signal, eso si que produce un crash inmediato.
eso de la reutilizacion es cierto, pero es muy poco probable que pase, para que un id de proceso se repita tras su destruccion deberias tener que tener corriendo en memoria unos 65535 procesos (que es la cantidad maxima de procesos que se pueden ejecutar), si no tienes esa cantidad de procesos corriendo, es un poco dificil (diria imposible) que te vaya a caer el mismo id que acabas de matar.
puede que en fenix o en las primeras versiones de bennugd, eso podia pasar, y de hecho habia serios problemas al respecto, pero ya hace mucho tiempo que en bennugd eso ya esta corregido.
Quote from: Fede on March 30, 2011, 06:51:07 PM
Gracias Splinter. Sabía que aparecerías a resolver mis dudas. :D
de na... para eso estamos.
También se puede dar si creas y destruyes procesos constantemente. 65535 procesos son muchos procesos, desde luego, pero un shooter algo larguito o un motor de tiles con mapas grandes puede dar la posibilidad (aunque por lo general, según mi experiencia, la variable que contiene la ID del proceso viejo suele cambiar de valor mucho antes de que eso ocurra :D).
Lo que no entiendo es la limitación del número máximo de procesos, no el número de procesos simultáneos, sino el numero máximo del ID, si no he contado mal son unos 14 bits que no se usan del "signed int".
Y lo que no sabía es que de 0 a 65535 era el tipo de proceso, mira tu ^^U
seguramente antes que se ejecuten los 65535 procesos (evidentemente, que mueran algunos) y te asigne un id nuevamente va a pasar un buen tiempo, e incluso hayas cambiado de nivel o hayas hecho cosas donde seguramente ya no tengas rastros de ese viejo id en tu codigo...
no tienes por que entender la limitacion de los 65535, pero si quieres te lo explico, aunque creo que ya lo hice muchas veces. es por una cuestion de performance... ademas, es totalmente ridiculo tener tantos procesos, ya que a los 10000 procesos todo el sistema crashea, por otras limitaciones...
si, los tipos de procesos son los primeros 65535, en fenix creo que eran menos, e incluso eran solo los impares...