Problema con la ejecución de cgi's

srfrogster · #1 (**permalink**) 08/01/2008, 08:13

Hola a todos,

Recientemente he tenido que instalar mod_perl en apache, con soporte para php y mysql (en un SO Solaris 10), pero me encuentro con el siguiente problema a la hora de ejecutar scripts cgi:

Resulta que el servidor arranca perfectamente, pero cuando llamo a un script cgi que contiene alguna de las siguientes funciones: dbmopen, dbmclose, tie, untie, me da un error de "segmentation fault" y genera un core file.

¿Me podríais ayudar alguno/a a solucionar esto, por favor?

Estoy utilizando: perl 5.8.4, apache 2.0.59, mod_perl 2.0.3, php 5.2.3, mysql 5.0.45.

Muchas gracias,
Héctor

jferrero · #2 (**permalink**) 08/01/2008, 09:21

Ese Perl es algo antiguo... vamos... más de dos años... yo lo actualizaría.

Haz un perl -V y nos lo mandas aquí.

srfrogster · #3 (**permalink**) 09/01/2008, 03:41

Hola de nuevo y gracias por la rápida contestación,
este es el informe que genera:

Summary of my perl5 (revision 5 version 8 subversion 4) configuration:
Platform:
osname=solaris, osvers=2.10, archname=i86pc-solaris-64int
uname='sunos localhost 5.10 i86pc i386 i86pc'
config_args=''
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=define use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TS_ERRNO',
optimize='',
cppflags=''
ccversion='Sun WorkShop', gccversion='', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='cc', ldflags =''
libpth=/lib /usr/lib /usr/ccs/lib
libs=-lsocket -lnsl -ldl -lm -lc
perllibs=-lsocket -lnsl -ldl -lm -lc
libc=/lib/libc.so, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-R /usr/perl5/5.8.4/lib/i86pc-solaris-64int/CORE'
cccdlflags='', lddlflags='-G'

Characteristics of this binary (from libperl):
Compile-time options: USE_64_BIT_INT USE_LARGE_FILES
Locally applied patches:
22667 The optree builder was looping when constructing the ops ...
22715 Upgrade to FileCache 1.04
22733 Missing copyright in the README.
22746 fix a coredump caused by rv2gv not fully converting a PV ...
22755 Fix 29149 - another UTF8 cache bug hit by substr.
22774 [perl #28938] split could leave an array without ...
22775 [perl #29127] scalar delete of empty slice returned garbage
22776 [perl #28986] perl -e "open m" crashes Perl
22777 add test for change #22776 ("open m" crashes Perl)
22778 add test for change #22746 ([perl #29102] Crash on assign ...
22781 [perl #29340] Bizarre copy of ARRAY make sure a pad op's ...
22796 [perl #29346] Double warning for int(undef) and abs(undef) ...
22818 BOM-marked and (BOMless) UTF-16 scripts not working
22823 [perl #29581] glob() misses a lot of matches
22827 Smoke [5.9.2] 22818 FAIL(F) MSWin32 WinXP/.Net SP1 (x86/1 cpu)
22830 [perl #29637] Thread creation time is hypersensitive
22831 improve hashing algorithm for ptr tables in perl_clone: ...
22839 [perl #29790] Optimization busted: '@a = "b", sort @a' ...
22850 [PATCH] 'perl -v' fails if local_patches contains code snippets
22852 TEST needs to ignore SCM files
22886 Pod::Find should ignore SCM files and dirs
22888 Remove redundant %SIG assignments from FileCache
23006 [perl #30509] use encoding and "eq" cause memory leak
23074 Segfault using HTML::Entities
23106 Numeric comparison operators mustn't compare addresses of ...
23320 [perl #30066] Memory leak in nested shared data structures ...
23321 [perl #31459] Bug in read()
27722 perlio.c breaks on Solaris/gcc when > 256 FDs are available
SPRINTF0 - fixes for sprintf formatting issues - CVE-2005-3962
Built under solaris
Compiled at Aug 8 2007 19:13:08
@INC:
/usr/perl5/5.8.4/lib/i86pc-solaris-64int
/usr/perl5/5.8.4/lib
/usr/perl5/site_perl/5.8.4/i86pc-solaris-64int
/usr/perl5/site_perl/5.8.4
/usr/perl5/site_perl
/usr/perl5/vendor_perl/5.8.4/i86pc-solaris-64int
/usr/perl5/vendor_perl/5.8.4
/usr/perl5/vendor_perl
.

De todas maneras, los mismos scripts cgi que estoy intentando ejecutar en esta máquina, funcionan en otra que tiene instalado perl 5.8.4, con lo que esto me despista un poco más si cabe.

jferrero · #4 (**permalink**) 09/01/2008, 04:53

Veo que hace uso de la libc. ¿Las dos máquinas tienen el mismo sistema operativo? ¿El mismo número de versión de libc?

Por otra parte, en las opciones de compilación no veo la inclusión de dbm. Por ejemplo:

Código:

Summary of my perl5 (revision 5 version 8 subversion 7) configuration:
  Platform:
    osname=linux, osvers=2.6.12, archname=i586-linux-thread-multi
    uname='linux xw8200 2.6.12 #1 smp wed dec 14 13:10:38 utc 2005 i686 i686 i386 gnulinux '
    config_args='-ds -e -Dprefix=/usr -Dvendorprefix=/usr -Dinstallusrbinperl -Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_gdbm -Duseshrplib=true -Doptimize=-O2 -march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -g -Wall -pipe'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
    usemymalloc=n, bincompat5005=undef

Y sí que despista esto... Si en otra máquina funciona, habrá que pensar que puede ser un fallo de las librerías. Sería MUY raro que sea debido a un fallo en los módulos que el programa necesite o un fallo del propio Perl (si es la misma versión en las dos máquinas y una funciona, es muy posible que tampoco sea el binario).

Haz un strace perl tu_script.cgi para ver dónde se cae. Digo strace, pero a lo mejor en Solaris ese comando se llama de otra manera. Me refiero a un programa que va mostrando las llamadas al sistema que nuestro programa va haciendo:
http://www.idevelopment.info/data/Un...nSolaris.shtml

srfrogster · #5 (**permalink**) 09/01/2008, 11:12

Pufff,
me parece que he encontrado dónde falla, pero no el porqué:
- Resulta que los ficheros ".dir" y ".pag" sobre los que hago el "dbmopen/tie" los he copiado vía ftp de la máquina en la que sí funciona.
- Al intentar abrir estos ficheros me da el error de "segmentation fault", pero si yo me genero con un script mi par de ficheros ".dir/.pag", sí que funciona y puedo añadirles datos y luego leerlos.
- Lo curioso viene ahora, según he comprobado en ambas máquinas, los ficheros "dir/pag" de una de ellas no funciona en la otra, es decir: Los ficheros "dir/pag" de la máquina 1 no son accesibles en la máquina 2 y los ficheros "dir/pag" creados en la máquina 2 no son accesibles en la máquina 1.
- Si quito los ficheros "dir/pag" conflictivos de la máquina donde me salía el error y ejecuto los cgi's, éstos funcionan de lujo.

Las diferencias que he visto entre ambas máquinas son:
Máquina 1 --> SunOS 5.8 en Inglés, con perl 5.8.7 (en el anterior mensaje puse que tenía un perl con 5.8.4 en la máquina en la que funcionaban los cgi's, en vez de 5.8.7....mis disculpas, porque me imagino que te habrá despistado)
Máquina 2 --> SunOS 5.10 en Español, con perl 5.8.4 (aquí es donde no funcionaba)

También he probado en otra máquina a la que tengo acceso:
Máquina 3 --> SunOS 5.8 en Inglés, con perl 5.8.6
En esta, se puede acceder a los "dir/pag" de la máquina 1, pero no a los de la máquina 2

Y por esto, me temo que pueda ser debido más al Solaris que al perl.

Aún así, he hecho un "truss -rall -wall" del script, como me indicaste, y el resultado de esto es que al principio sí que lee bien los ficheros, pero llega un momento en el que empieza a generar breaks en muchísimas direcciones de memoria y finalmente da un error gordo y termina:

brk(0x08946348) = 0
brk(0x08946348) = 0
brk(0x0894C348) = 0
Incurred fault #6, FLTBOUNDS %pc = 0xD25E6B64
siginfo: SIGSEGV SEGV_MAPERR addr=0x0894D000
Received signal #11, SIGSEGV [default]
siginfo: SIGSEGV SEGV_MAPERR addr=0x0894D000

Por lo que he estado leyendo por ahí, parece que este error surge cuando se está intentando acceder a una posición de memoria más allá de la que tiene mapeada el kernel (casi nada). El motivo de que se dé el error aquí y no en la otra máquina.....¿igual pudiera ser porque esta máquina es en realidad un servidor virtual? ¿puede ser que desde este servidor virtual se esté intentando acceder a posiciones de memoria que pertenecen a otro servidor virtual dentro de la misma máquina física?....ni idea, habrá que seguir dándole vueltas

jferrero · #6 (**permalink**) 09/01/2008, 12:38

Yo supongo que habrás copiado los ficheros por ftp en modo binario...

En cuanto al fallo, podría ser que las librerías dbm fueran distintas... o que al estar compiladas en una máquina de 64 bits saliese ese problema...

He mirado perlsolaris y perl585delta, perl586delta y perl587delta, pero no hay comentarios sobre problemas con dbm o si han cambiado de librerías de una versión a otra o es que no son compatibles con los 64 bits...

¿Esos Perl los has compilado tu o venían de fábrica? Si es por eso encontré un mensaje por Internet con "the segfault disappears when compiling in 32bit mode with -Duse64bitint (-Dusethreads still being there)".

Habría que mirar más específicamente en los sitios de Solaris... creo.

srfrogster · #7 (**permalink**) 10/01/2008, 07:29

sí, no te preocupes, que ya me conozco lo de los modos binario y ascii de aventuras pasadas jejeje

En cuanto a lo del perl, es cierto que en la máquina en la que falla, la del solaris 10, esa versión de perl 5.8.4 viene incluída con el sistema operativo (en las otras máquina se instaló otra versión aparte de la que venía con el SO) y puede que sea algo de lo que dices, que para esa plataforma y ese solaris las opciones de compilación que tiene el perl pudieran dar problemas si se tratara de reutilizar algo desde otras máquinas diferentes.

Me miraré la documentación de Solaris y el tipo de fallo que has encontrado a ver si doy con alguna pista más y también de paso para ver si hubiera algo más por ahí que me pudiera dar problemas.

Ya te diré qué he visto por ahí...
Muchas gracias por todo