Well at last the core where produced.
When called gdb with the httpd executable and the core file, gdb shows
this:
Core was generated by `/usr/eBD/bin/httpd'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/tls/libpthread.so.0...done.
Loaded symbols for /lib/tls/libpthread.so.0
Reading symbols from /lib/tls/libm.so.6...done.
Loaded symbols for /lib/tls/libm.so.6
..
..
..
Loaded symbols for
/usr/eBD/perl//i386-linux-thread-multi/auto/DBD/ODBC/ODBC.so
Reading symbols from /usr//lib/libodbc.so.1...done.
Loaded symbols for /usr//lib/libodbc.so.1
Reading symbols from /usr/lib/gconv/ISO8859-1.so...done.
Loaded symbols for /usr/lib/gconv/ISO8859-1.so
#0 0x4018de75 in Perl_hv_free_ent (my_perl=0x85ba6d8, hv=0xd103fd0,
entry=0xcfdb698) at hv.c:1592
1592 hv.c: No such file or directory.
in hv.c
(gdb)
This hv.c error is because gdb didn't find this file?
Or this is really the originator of the Segfault?
On dv, 2004-11-05 at 13:38, Marc Gracia wrote:
> Hi everybody.
> I have a problem on a production cluster with a somewhat big mod_perl
> app, and I just cannot get any clue of what is happening.
>
> The problem is that the servers just exit with Segmentation fault
> randomly.
> The problem is rare, hapens 10/20 times each day in each of the 6
> frontends, which globaly processes about 1.000.000 daily hits.
> The global stats show about 30 Internal server errors daily, I don't
> know if a segfault can cause an Internal Server Error on the client (I
> suppose not, if the server dies, cannot send the 505), but the numbers
> don't match anyway.
>
> I think a coredump will help me understand why it segfaults, but I don't
> know how to make apache dump a coredump, I've tried a lot of recipes
> found on internet with any success. Making things more complicated, this
> problems only happens on the production systems, (Suppose only on some
> pages...) so I cannot reproduce it on my test system.
>
> So, my question is... There is any way to force apache to dump a
> coredump file? I suppose I'm forgotting something but I really
> desperate...
>
> A secondary question is, some of the servers transforms all UTF8 strings
> with "garbage" when some Segfault happens (Seems like double-encoded
> UTF8, the page shows 3 or 4 chars for every UTF8 char...). The only way
> to solve this is reboot the machine completely.
> Is that related to this same problem? Or is an obscure UTF8 perl/Apache
> problem?
>
> Many thanks,
> I'm using mod_perl 1.29 with apache 1.3.31.
> My perl conf:
>
> Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
> Platform:
> osname=linux, osvers=2.4.20-2.48smp,
> archname=i386-linux-thread-multi
> uname='linux str'
> config_args='-des -Doptimize=-O2 -march=i386 -mcpu=i686 -g
> -Dmyhostname=localhost [EMAIL PROTECTED] -Dcc=gcc -Dcf_by=Red
> Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux
> -Dvendorprefix=/usr -Dsiteprefix=/usr
> -Dotherlibdirs=/usr/lib/perl5/5.8.0 -Duseshrplib -Dusethreads
> -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db
> -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio
> -Dinstallusrbinperl -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less
> -isr'
> hint=recommended, useposix=true, d_sigaction=define
> usethreads=define use5005threads=undef'
> useithreads=define usemultiplicity=
> useperlio= d_sfio=undef uselargefiles=define usesocks=undef
> use64bitint=undef use64bitall=un uselongdouble=
> usemymalloc=, bincompat5005=undef
> Compiler:
> cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS
> -DDEBUGGING -fno-strict-aliasing -I/usr/local/include
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
> optimize='',
> cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING
> -fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm'
> ccversion='', gccversion='3.2.2 20030213 (Red Hat Linux 8.0
> 3.2.2-1)', gccosandvers=''
> gccversion='3.2.2 200302'
> intsize=e, longsize= , ptrsize=p, doublesize=8, byteorder=1234
> d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
> ivtype='long'
> k', ivsize=4'
> ivtype='long'
> known_ext, nvtype='double'
> o_nonbl', nvsize=, Off_t='', lseeksize=8
> alignbytes=4, prototype=define
> Linker and Libraries:
> ld='gcc'
> l', ldflags =' -L/usr/local/lib'
> ldf'
> libpth=/usr/local/lib /lib /usr/lib
> libs=-lnsl -lgdbm -ldb -ldl -lm -lpthread -lc -lcrypt -lutil
> perllibs=
> libc=/lib/libc-2.3.1.so, so=so, useshrplib=true, libperl=libper
> gnulibc_version='2.3.1'
> Dynamic Linking:
> dlsrc=dl_dlopen.xs, dlext=so', d_dlsymun=undef, ccdlflags='-rdynamic
> -Wl,-rpath,/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE'
> cccdlflags='-fPIC'
> ccdlflags='-rdynamic -Wl,-rpath,/usr/lib/perl5', lddlflags='s
> Unicode/Normalize XS/A'
>
>
> Characteristics of this binary (from libperl):
> Compile-time options: DEBUGGING MULTIPLICITY USE_ITHREADS
> USE_LARGE_FILES PERL_IMPLICIT_CONTEXT
> Locally applied patches:
> MAINT18379
> Built under linux
> Compiled at Feb 18 2003 22:19:53
> %ENV:
> PERL5LIB="/usr/eBD/perl"
> @INC:
> /usr/eBD/perl/i386-linux-thread-multi
> /usr/eBD/perl
> /usr/lib/perl5/5.8.0/i386-linux-thread-multi
> /usr/lib/perl5/5.8.0
> /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi
> /usr/lib/perl5/site_perl/5.8.0
> /usr/lib/perl5/site_perl
> /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi
> /usr/lib/perl5/vendor_perl/5.8.0
> /usr/lib/perl5/vendor_perl
> /usr/lib/perl5/5.8.0/i386-linux-thread-multi
> /usr/lib/perl5/5.8.0
>
>
>
>
--
Marc Gracia <[EMAIL PROTECTED]>
Oasys Soft
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
