Re: How to get a core dump
[prev]
[thread]
[next]
[Date index for 2004/11/08]
Hi,
Well, It's only 2 hours of on line testing, but seems that the
recompilation and upgrade to apache-1.3.33 I did with "-g" to get debug
info on coredumps solved the problem....
I used exactly the same configure options on apache,mod_ssl and mod_perl
(I used the same shell script, in fact)
Now I don't know what caused the problem first place, but now seems ok.
I taked in account that first time I compiled all on a shell with
"en_US" locale, and now I used one with "en_US.UTF8".
May the locale used in the shell to compile apache+mod_perl affect the
final executable in some way?
The server has to deal with UTF8 info coming from/going to a SQLServer
backend...
On dv, 2004-11-05 at 17:46, Marc Gracia wrote:
> Many Thanks Stass and Glenn,
> I'll try all this anf will get back..
>
> 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 -Dperladmin=root@localhost -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 <mgracia@xxxxxxxxx.xxx>
> 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
