Bug 127506

Description of problem:
just creating a database handle then destroying it in a continous loop
leaks memory at the rate of 2x every 15 minutes.

Version-Release number of selected component (if applicable):
Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
  Platform:
    osname=linux, osvers=2.4.21-1.1931.2.393.entsmp,
archname=i386-linux-thread-multi
    uname='linux por'
    config_args='-des -Doptimize=-O2 -g -pipe -march=i386 -mcpu=i686
-Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red
Hat, Inc. -Dinsta\
llprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr
-Dsiteprefix=/usr -Dotherlibdirs=/usr/lib/perl5/5.8.0 -Duseshrplib
-Dusethreads -Duseit\
hreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm
-Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio
-Dinstallusrbinperl -Ubincompat50\
05 -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_OFFS\
ET_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.3 20030502 (Red Hat Linux
3.2.3-19)', gccosandvers=''
gccversion='3.2.3 200305'
    intsize=o, longsize=s, ptrsize=l, doublesize=8, byteorder=1234
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long'
k', ivsize=4'
ivtype, nvtype='double'
o_no', nvsize=, Off_t='', lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='gcc'
l', ldflags =' -L/usr/local/lib'
ldflags_use'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -lgdbm -ldb -ldl -lm -lpthread -lc -lcrypt -lutil
    perllibs=
    libc=/lib/libc-2.3.2.so, so=so, useshrplib=true, libperl=libper
    gnulibc_version='2.3.2'
  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 Sep 15 2003 10:03:52


How reproducible:


Steps to Reproduce:
just run the following script: (need a database)
#!/usr/bin/perl

use strict;

use DBI;

while (1) {
    my $nom_bd = 'caprd';
    my $mdp = 'mypass';
    my $usager = 'myuser';
    my $DBI = "dbi:Oracle:$nom_bd";

    my $dbo = DBI -> connect ($DBI,$usager,$mdp, {  RaiseError => 1,
AutoCommit => 1  } );
    unless ($dbo) {
        sleep(10);
        next;
    }

    $dbo->disconnect; $dbo=0;     # Close handler for oracle
    undef $dbo;
    sleep(1);

    next;
}


1.
2.
3.
  
Actual results:
start run on Thu Jul  8 21:00:33 EDT 2004
memory the application uses: 7040
check at: Thu Jul  8 21:18:09 EDT 2004
memory the application now uses: 14020

Expected results:
if other database operations are present (statements, etc) the rate of
memory leak is even higher.

Additional info: