From jose.de.arce en gmail.com Thu Jan 8 01:42:30 2009 From: jose.de.arce en gmail.com (Jose Manuel de Arce) Date: Thu, 8 Jan 2009 10:42:30 +0100 Subject: [Madrid-pm] =?iso-8859-1?q?Feliz_a=F1o_nuevo=2C_y_una_cuestion?= Message-ID: <90af03ba0901080142n2c0fab52hd131582096f6a882@mail.gmail.com> Estimados, lo primero, felicitar el año nuevo a todos. Ahora me animo a describir una situación por si alguien ha tenido una experiencia parecida. En linux, slackware, una serie de scripts (en perl, claro) que leen correo por pop3 y procesan los mensajes se invocan por cron cada cierto tiempo (5 minutos). Graban algunos ficheros en disco y ya. Esto funciona desde principios de Diciembre, y al cabo de un tiempo variable, desde 10 días hasta 2 días, el binario perl ya no funciona, cualquier invocacion se salda con un "Segmentation Fault". desde el shell, haciendo perl -v, segmentation fault. El resto de procesos funciona sin problema y se pueden lanzar otros binarios. un strace, que es lo que he sabido hacer, (strace perl -v) termina con: . . . mmap2(NULL, 178476, PROT_READ, MAP_PRIVATE, 3, 0) = 0x401d3000 close(3) = 0 open("/dev/urandom", O_RDONLY|O_LARGEFILE) = 3 read(3, "\t\234\224\246", 4) = 4 close(3) = 0 time([1231407045]) = 1231407045 mmap2(NULL, 135462912, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x401ff000 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ Y no tengo otra forma de recuperar la situacion que rebotando. Parece que algo queda en memoria, sticky, entre invocaciones. los scripts terminan con normalidad hasta que dejan de hacerlo, y ya no se puede usar perl. Parece que el uso repetido,, via cron, y la invocacion muchas veces, dejara algo en memoria, o en cache, o no sé dónde, que no puedo vaciar, y provoca lo que describo. Alguna pista de como evitar esto o como corregir esta situacion sin rebotar? Gracias josema From nacho en sandboxed.org Thu Jan 8 07:11:47 2009 From: nacho en sandboxed.org (Nacho) Date: Thu, 08 Jan 2009 16:11:47 +0100 Subject: [Madrid-pm] =?iso-8859-1?q?Feliz_a=F1o_nuevo=2C_y_una_cuestion?= In-Reply-To: <90af03ba0901080142n2c0fab52hd131582096f6a882@mail.gmail.com> References: <90af03ba0901080142n2c0fab52hd131582096f6a882@mail.gmail.com> Message-ID: <496617B3.7000502@sandboxed.org> Jose Manuel de Arce escribió: > Estimados, > > lo primero, felicitar el año nuevo a todos. Feliz año! > Ahora me animo a describir una situación por si alguien ha tenido una > experiencia parecida. > > En linux, slackware, una serie de scripts (en perl, claro) que leen > correo por pop3 y procesan los mensajes se invocan por cron cada > cierto tiempo (5 minutos). Graban algunos ficheros en disco y ya. Esto > funciona desde principios de Diciembre, y al cabo de un tiempo > variable, desde 10 días hasta 2 días, el binario perl ya no funciona, > cualquier invocacion se salda con un "Segmentation Fault". ¿Podrías pasar los scripts adjuntos en un correo? Quizás el problema esté en cómo se declaran las variables ó cuánta información se almacena en ellas. Basta con que se consuma más memoria de lo esperado para provocar un fallo de segmentación. > desde el shell, haciendo perl -v, segmentation fault. El resto de > procesos funciona sin problema y se pueden lanzar otros binarios. Revisa este post en perlmonks, quizás pueda ayudarte. ¿Qué peso tienen los scripts a nivel de consumo de recursos? http://www.perlmonks.org/?node_id=651966 "It is possible to get segmentation faults by exceeding the maximum memory in perl. In theory this could also happen with a bad Storable file, i.e. if some wrong length parameter causes memory overflow..." > un strace, que es lo que he sabido hacer, (strace perl -v) termina con: > . > . > . > mmap2(NULL, 178476, PROT_READ, MAP_PRIVATE, 3, 0) = 0x401d3000 > close(3) = 0 > open("/dev/urandom", O_RDONLY|O_LARGEFILE) = 3 > read(3, "\t\234\224\246", 4) = 4 > close(3) = 0 > time([1231407045]) = 1231407045 > mmap2(NULL, 135462912, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x401ff000 > --- SIGSEGV (Segmentation fault) @ 0 (0) --- > +++ killed by SIGSEGV +++ > > Y no tengo otra forma de recuperar la situacion que rebotando. > > Parece que algo queda en memoria, sticky, entre invocaciones. los > scripts terminan con normalidad hasta que dejan de hacerlo, y ya no se > puede usar perl. > > Parece que el uso repetido,, via cron, y la invocacion muchas veces, > dejara algo en memoria, o en cache, o no sé dónde, que no puedo > vaciar, y provoca lo que describo. > > Alguna pista de como evitar esto o como corregir esta situacion sin rebotar? No tengo mucha idea de perl, pero espero que pueda servirte de ayuda. Feliz año a todos. From jose.de.arce en gmail.com Fri Jan 9 11:27:33 2009 From: jose.de.arce en gmail.com (Jose Manuel de Arce) Date: Fri, 9 Jan 2009 20:27:33 +0100 Subject: [Madrid-pm] =?iso-8859-1?q?Feliz_a=F1o_nuevo=2C_y_una_cuestion?= In-Reply-To: <496617B3.7000502@sandboxed.org> References: <90af03ba0901080142n2c0fab52hd131582096f6a882@mail.gmail.com> <496617B3.7000502@sandboxed.org> Message-ID: <90af03ba0901091127g6f3b3a04j10bf3caf83368e99@mail.gmail.com> Hola > > ¿Podrías pasar los scripts adjuntos en un correo? Quizás el problema esté en > cómo se declaran las variables ó cuánta información se almacena en ellas. > Basta con que se consuma más memoria de lo esperado para provocar un fallo > de segmentación. > en cron, cada 5 minutos: 4,9,14,19,24,29,34,39,44,49,54,59 * * * * /usr/bin/perl/currentprocesa.pl < current_camBE0301.txt > current_camBE0301.xml el script en este caso se llama currentprocesa y esta adjunto. Es de lo mas normal ... > > Revisa este post en perlmonks, quizás pueda ayudarte. ¿Qué peso tienen los > scripts a nivel de consumo de recursos? > nada importante, leer un txt y escribir un txt. > http://www.perlmonks.org/?node_id=651966 > > "It is possible to get segmentation faults by exceeding the maximum memory > in perl. > ... no uso modulos de los mencionados. Gracias! ------------ próxima parte ------------ An embedded and charset-unspecified text was scrubbed... Name: currentprocesa.anonimo.pl URL: From pancho en pancho.name Sun Jan 11 13:38:51 2009 From: pancho en pancho.name (pancho horrillo) Date: Sun, 11 Jan 2009 22:38:51 +0100 Subject: [Madrid-pm] =?iso-8859-1?q?Feliz_a=F1o_nuevo=2C_y_una_cuestion?= In-Reply-To: <90af03ba0901080142n2c0fab52hd131582096f6a882@mail.gmail.com> References: <90af03ba0901080142n2c0fab52hd131582096f6a882@mail.gmail.com> Message-ID: <20090111213851.GA6423@pancho.name> On Thu, Jan 08, 2009 at 10:42:30AM +0100, Jose Manuel de Arce wrote: > Estimados, > Saludos, terrícola! > lo primero, felicitar el año nuevo a todos. > Feliz ciclo solar. > Ahora me animo a describir una situación por si alguien ha tenido una > experiencia parecida. > > En linux, slackware, una serie de scripts (en perl, claro) que leen > correo por pop3 y procesan los mensajes se invocan por cron cada > cierto tiempo (5 minutos). Graban algunos ficheros en disco y ya. Esto > funciona desde principios de Diciembre, y al cabo de un tiempo > variable, desde 10 días hasta 2 días, el binario perl ya no funciona, > cualquier invocacion se salda con un "Segmentation Fault". > > desde el shell, haciendo perl -v, segmentation fault. El resto de > procesos funciona sin problema y se pueden lanzar otros binarios. > Recreación del delito: 0. system boot. 1. crond arranca, y ejecuta un script perl, que fuerza la carga de su intérprete, /usr/bin/perl. Como buen hijo de UNIX®, linux lee el binario del disco y lo carga en el buffer caché. 2. linux crea un proceso perl a partir de la imagen recién cargada en el buffer caché. 3. El script finaliza, el proceso se muere, un funeral austero, etc. 4. crond sigue invocando al script cada 5 minutos, repitiéndose la creación del proceso perl a partir de la imagen almacenada en el buffer caché. Es decir, la imagen /usr/bin/perl no se vuelve a leer del disco. So far so good. 5. En algún momento, debido a un bug de linux o tal vez memoria RAM defectuosa, la imagen de /usr/bin/perl en el buffer caché se corrompe un pelín. 6. Las subsiguientes invocaciones al binario perl acaban ejecutando dicha imagen corrupta, concluyendo en una desreferencia de NULL (0), lo que hace que el linux se enfurezca y le envíe una señal fulminante, como caída del cielo. Si esto es lo que pasa, recomiendo hacer una copia a priori del binario /usr/bin/perl en otra parte, digamos /usr/local/bin/perl. Cuando se alcanza el estado del paso #5, probar a ver si la copia (que aún no está en el buffer caché), se ejecuta. A simple /usr/local/bin/perl -v will suffice. Esta condición podría ser debida a un fallo de la RAM. ¿La máquina tiene memoria ECC? Si no, antes o despues algún bit se invierte, y la información contenida se corrompe. Una pasadita de memtest86+ no vendría mal, at any rate, por si hay bits que fallen de forma sistemática. La versión de la slackware, perl, el linux, así como el .config de éste podrían venir bien para saber a qué nos enfrentamos. Quizá el fallo esté en el kernel. Hope that it helps. Un saludo, pancho. > un strace, que es lo que he sabido hacer, (strace perl -v) termina con: > . > . > . > mmap2(NULL, 178476, PROT_READ, MAP_PRIVATE, 3, 0) = 0x401d3000 > close(3) = 0 > open("/dev/urandom", O_RDONLY|O_LARGEFILE) = 3 > read(3, "\t\234\224\246", 4) = 4 > close(3) = 0 > time([1231407045]) = 1231407045 > mmap2(NULL, 135462912, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x401ff000 > --- SIGSEGV (Segmentation fault) @ 0 (0) --- > +++ killed by SIGSEGV +++ > > Y no tengo otra forma de recuperar la situacion que rebotando. > > Parece que algo queda en memoria, sticky, entre invocaciones. los > scripts terminan con normalidad hasta que dejan de hacerlo, y ya no se > puede usar perl. > > Parece que el uso repetido,, via cron, y la invocacion muchas veces, > dejara algo en memoria, o en cache, o no sé dónde, que no puedo > vaciar, y provoca lo que describo. > > Alguna pista de como evitar esto o como corregir esta situacion sin rebotar? > > Gracias > > josema > _______________________________________________ > Madrid-pm mailing list > Madrid-pm at pm.org > http://mail.pm.org/mailman/listinfo/madrid-pm -- pancho horrillo To be conscious that you are ignorant is a great step to knowledge. Benjamin Disraeli -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From jose.de.arce en gmail.com Mon Jan 12 02:03:25 2009 From: jose.de.arce en gmail.com (Jose Manuel de Arce) Date: Mon, 12 Jan 2009 11:03:25 +0100 Subject: [Madrid-pm] =?iso-8859-1?q?Feliz_a=F1o_nuevo=2C_y_una_cuestion?= In-Reply-To: <20090111213851.GA6423@pancho.name> References: <90af03ba0901080142n2c0fab52hd131582096f6a882@mail.gmail.com> <20090111213851.GA6423@pancho.name> Message-ID: <90af03ba0901120203u10ad9fadoc8773fbf8d5a814b@mail.gmail.com> Hola Gracias, la explicación es lógica y me encaja con lo que pasa. Es el carácter "sticky" que yo comentaba y que tu has ilustrado perfectamente. El PC donde corre esto es un viejo Medion de MediaMarkt del año 2001 que aunque pasa el test de memoria, me ha dado multitud de problemas que solo se explican por un HW defectuoso. Buscaré si hay forma de hacer que el binario no se quede en la buffer cache. Gracias Josema El día 11 de enero de 2009 22:38, pancho horrillo escribió: > On Thu, Jan 08, 2009 at 10:42:30AM +0100, Jose Manuel de Arce wrote: >> Estimados, >> > Saludos, terrícola! > >> lo primero, felicitar el año nuevo a todos. >> > Feliz ciclo solar. > >> Ahora me animo a describir una situación por si alguien ha tenido una >> experiencia parecida. >> >> En linux, slackware, una serie de scripts (en perl, claro) que leen >> correo por pop3 y procesan los mensajes se invocan por cron cada >> cierto tiempo (5 minutos). Graban algunos ficheros en disco y ya. Esto >> funciona desde principios de Diciembre, y al cabo de un tiempo >> variable, desde 10 días hasta 2 días, el binario perl ya no funciona, >> cualquier invocacion se salda con un "Segmentation Fault". >> >> desde el shell, haciendo perl -v, segmentation fault. El resto de >> procesos funciona sin problema y se pueden lanzar otros binarios. >> > Recreación del delito: > > 0. system boot. > > 1. crond arranca, y ejecuta un script perl, que fuerza la carga de su > intérprete, /usr/bin/perl. Como buen hijo de UNIX(R), linux lee el > binario del disco y lo carga en el buffer caché. > > 2. linux crea un proceso perl a partir de la imagen recién cargada en el > buffer caché. > > 3. El script finaliza, el proceso se muere, un funeral austero, etc. > > 4. crond sigue invocando al script cada 5 minutos, repitiéndose la > creación del proceso perl a partir de la imagen almacenada en el buffer > caché. Es decir, la imagen /usr/bin/perl no se vuelve a leer del disco. > So far so good. > > 5. En algún momento, debido a un bug de linux o tal vez memoria RAM > defectuosa, la imagen de /usr/bin/perl en el buffer caché se corrompe un > pelín. > > 6. Las subsiguientes invocaciones al binario perl acaban ejecutando > dicha imagen corrupta, concluyendo en una desreferencia de NULL (0), lo > que hace que el linux se enfurezca y le envíe una señal fulminante, como > caída del cielo. > > > Si esto es lo que pasa, recomiendo hacer una copia a priori del binario > /usr/bin/perl en otra parte, digamos /usr/local/bin/perl. Cuando se > alcanza el estado del paso #5, probar a ver si la copia (que aún no está > en el buffer caché), se ejecuta. A simple /usr/local/bin/perl -v will > suffice. > > Esta condición podría ser debida a un fallo de la RAM. ¿La máquina > tiene memoria ECC? Si no, antes o despues algún bit se invierte, y la > información contenida se corrompe. Una pasadita de memtest86+ no > vendría mal, at any rate, por si hay bits que fallen de forma > sistemática. > > La versión de la slackware, perl, el linux, así como el .config de éste > podrían venir bien para saber a qué nos enfrentamos. Quizá el fallo > esté en el kernel. > > Hope that it helps. > > Un saludo, > > pancho. > >> un strace, que es lo que he sabido hacer, (strace perl -v) termina con: >> . >> . >> . >> mmap2(NULL, 178476, PROT_READ, MAP_PRIVATE, 3, 0) = 0x401d3000 >> close(3) = 0 >> open("/dev/urandom", O_RDONLY|O_LARGEFILE) = 3 >> read(3, "\t\234\224\246", 4) = 4 >> close(3) = 0 >> time([1231407045]) = 1231407045 >> mmap2(NULL, 135462912, PROT_READ|PROT_WRITE, >> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x401ff000 >> --- SIGSEGV (Segmentation fault) @ 0 (0) --- >> +++ killed by SIGSEGV +++ >> >> Y no tengo otra forma de recuperar la situacion que rebotando. >> >> Parece que algo queda en memoria, sticky, entre invocaciones. los >> scripts terminan con normalidad hasta que dejan de hacerlo, y ya no se >> puede usar perl. >> >> Parece que el uso repetido,, via cron, y la invocacion muchas veces, >> dejara algo en memoria, o en cache, o no sé dónde, que no puedo >> vaciar, y provoca lo que describo. >> >> Alguna pista de como evitar esto o como corregir esta situacion sin rebotar? >> >> Gracias >> >> josema >> _______________________________________________ >> Madrid-pm mailing list >> Madrid-pm en pm.org >> http://mail.pm.org/mailman/listinfo/madrid-pm > > -- > pancho horrillo > > To be conscious that > you are ignorant is a great step > to knowledge. > > Benjamin Disraeli > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAklqZukACgkQ64HQYZTzLDlJ2wCfTEIQxr2E0pDY8VeIsma3x5qO > q9UAoIDf+olmRouaITptvz5HoDE84Xa7 > =SdJH > -----END PGP SIGNATURE----- > > _______________________________________________ > Madrid-pm mailing list > Madrid-pm en pm.org > http://mail.pm.org/mailman/listinfo/madrid-pm >