Re: How to get a core dump

[prev] [thread] [next] [Date index for 2004/11/08]

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 -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