php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #19213 odbc_close() not working?
Submitted: 2002-09-03 13:26 UTC Modified: 2002-10-27 19:43 UTC
Votes:2
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:1 (100.0%)
From: a dot steckenborn at stebosoft dot de Assigned:
Status: Not a bug Package: ODBC related
PHP Version: 4.3.0-dev OS: SuSE Linux 8.0
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: a dot steckenborn at stebosoft dot de
New email:
PHP Version: OS:

 

 [2002-09-03 13:26 UTC] a dot steckenborn at stebosoft dot de 
With each connection to our Database over PHP Script the used Memory of our HTTP childs is growing up.
At the beginning the Memory is around 2000k per Child. After 3 Days around 50MB per child.
After 5 Days the System is using 300 MB Swap and crashes.

I'm working with this Problem longer than 8 month now, but i cant't find out what it is.
Before our Webserver was SuSE Linux 6.0. I've updated now to
8.0, newest Apache 1.x newest PHP.

Our Webserver with PHP and Adabas D 11.01 for Customer Database with small tables.
Seperate Database Machine (SuSE 8.0) for big tables.

We are using
ODBC_Free_Result($res)
and
ODBC_Close ($conn)

in all Scripts

but the used memory will grow around 80k up per result.

I hope that you can help me to fix this bug.

Dear 

Albert Steckenborn

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-09-03 16:05 UTC] edink@php.net 
As a temporary workaround you can set

MaxRequestsPerChild 100

in your apache configuration.
 [2002-09-03 17:23 UTC] a dot steckenborn at stebosoft dot de 
this is my /var/spool/sql/config/odbc.ini
++++++++++++++++++++++++++++++++++++++++++
[LM]
DSN = 192.168.10.5:LM
SERVERDB = LM
SERVER = adabas1
SERVERNODE = 192.168.10.5 
[CUST]
DSN = 192.168.10.2:CUST
SERVERDB = CUST
SERVER = server
SERVERNODE = 192.168.10.2 
++++++++++++++++++++++++++++++++++++++++++++

This is a little script that takes between 24k and 40k Memory:
<?
include("include/ODBC_Connect.phtml");
       if ($where == null) { $where="";}
         if ($conn1) {
           $sql = "select VA_STARTCODE,VA_NAME from R_VERANSTALTER where LAST_ACTIV <>'N' and LAST_ART <>'NF' ".$where1;
           $sql .= " order by VA_STARTCODE DESC ";
           $res = ODBC_Exec($conn1,$sql);
           if ($res) {
                while (ODBC_Fetch_Row($res)) {
                        $a = ODBC_Result($res,1);
                        $b = ODBC_Result($res,2);
                        printf("%s %s\n",$a,$b);
                }
           ODBC_Free_Result($res);
           }
         ODBC_Close($conn1);
        }
?>

without the odbc connect it takes no Memory away.
 [2002-09-03 17:39 UTC] kalowsky@php.net 
what odbc connection call?
 [2002-09-03 17:59 UTC] a dot steckenborn at stebosoft dot de 
$conn1= @ODBC_Connect("CUST",$USER,$PASSWORD);
 [2002-09-03 18:04 UTC] kalowsky@php.net 
Everything looks good in your sample script.  Any chance you can test out the latest snapshot for 4.2.3?  There were a handful of memory fixes added to it, which might clean up your problem a bit.  

Although I don't think it will take all of it away.
 [2002-09-03 18:16 UTC] a dot steckenborn at stebosoft dot de 
I will try that tomorrow.
Hope that it will fix the bug.
At the Moment i will restart the Apache each night, but
the traffic is growing up and it's only a question of
time that i have to restart the Web-Server 2 Times per
Day and then i will get a lot of troubles with my Customers.
The last month my business was searching this bug and I hope
that I will get it.

I will post tomorrow if it works with the new Snapshot.

Thanks and best rgds.

Albert
 [2002-09-03 18:23 UTC] kalowsky@php.net 
Keeping as feedback until we hear back from you on the snapshot.
 [2002-09-04 02:47 UTC] a dot steckenborn at stebosoft dot de 
Hello,

using now PHP4.3.0-DEV.
Nothing has changed.

Without

ODBC_Free_Result($res)
 and 
ODBC_Close($conn)

it looks the same as with freeing Results and Close Connection.

I've seen in the bug reports that there was a bug like this
with db2 that was fixed.

Hope that it will help.

with best rgds.

Albert
 [2002-09-04 08:12 UTC] a dot steckenborn at stebosoft dot de 
here there are my config flags:
'./configure' '--with-adabas=/usr/local/adabas' '--with-mysql=/usr/local/mysql' '--with-pdflib=/usr/local/pdflib/bind/c/' '--enable-dbase' '--with-db' '--with-jpeg-dir=/usr/lib/' '--with-apsx2' '--with-apsx' '--with-png-dir=/usr/lib/' '--with-zlib' '--with-apache=../apache_1.3.26'

php.ini flags:
In previus Version of PHP i don't have to set the odbc.default_db but with PHP4.2.2. the connection don't works without

odbc.default_db   /var/spool/sql/config/odbc.ini

Now with PHP4.3-DEV it works without the setting again.

At the moment it works a little bit better than before, but the bug is not fixed.(Memory don't grow so fast)

I will copy from TOP
the memory usage of the httpd childs
at the moment
after 6hours
tomorrow at 8:00am (CET)
without restarting apache and setting 
MaxRequestsPerChild 0

and post it here.

So it's better to see how the memory grows up.

with best rgds.

Albert
 [2002-09-04 10:08 UTC] kalowsky@php.net 
Okay that default_db is a McGuffin, as that functionality isn't even enabled in PHP.  It was to be, but all work has stopped on it at this time.
 [2002-09-04 13:04 UTC] a dot steckenborn at stebosoft dot de 
Here you can see how the used memory grows up:

Memory usage of http childs 20020904 03:00PM

26074 wwwrun    13   0  6604 6604  3644 S     0.0  1.2   0:00 httpd
26069 wwwrun    20   0  6380 6380  3624 S     0.0  1.2   0:00 httpd
26073 wwwrun    20   0  6060 6060  3476 S     0.0  1.1   0:01 httpd
26077 wwwrun    20   0  5904 5904  3436 S     0.0  1.1   0:00 httpd
26070 wwwrun    20   0  5272 5272  3616 S     0.0  1.0   0:00 httpd
26071 wwwrun    20   0  5112 5112  3632 S     0.0  0.9   0:00 httpd
26078 wwwrun    20   0  4640 4640  3472 S     0.0  0.9   0:00 httpd
26072 wwwrun    20   0  4552 4552  3616 S     0.0  0.8   0:00 httpd
26076 wwwrun    20   0  4436 4436  3464 S     0.0  0.8   0:00 httpd
26075 wwwrun    20   0  4368 4368  3432 S     0.0  0.8   0:00 httpd
26302 wwwrun    20   0  4136 4136  3416 S     0.0  0.8   0:00 httpd
26298 wwwrun    20   0  4064 4064  3420 S     0.0  0.7   0:00 httpd
26068 root      20   0  2828 2828  2620 S     0.0  0.5   0:00 httpd

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Memory usage of http childs 20020904 08:00PM

26071 wwwrun    20   0 11288  11M  3704 S     0.0  2.1   0:06 httpd
26070 wwwrun    20   0 10392  10M  3680 S     0.0  2.0   0:05 httpd
26076 wwwrun    19   0  9444 9444  3556 S     0.0  1.8   0:05 httpd
26073 wwwrun    19   0  9252 9252  3540 S     0.0  1.8   0:06 httpd
26072 wwwrun    20   0  9232 9232  3680 S     0.0  1.7   0:05 httpd
26074 wwwrun    20   0  9160 9160  3688 S     0.0  1.7   0:04 httpd
26069 wwwrun    20   0  9048 9048  3696 S     0.0  1.7   0:05 httpd
26075 wwwrun    19   0  8712 8712  3528 S     0.0  1.6   0:05 httpd
26456 wwwrun    19   0  8504 8504  3544 S     0.0  1.6   0:04 httpd
26298 wwwrun    20   0  8468 8468  3552 S     0.0  1.6   0:04 httpd
26077 wwwrun    20   0  8404 8404  3544 S     0.0  1.6   0:07 httpd
26078 wwwrun    20   0  8256 8256  3532 S     0.0  1.6   0:05 httpd
26458 wwwrun    20   0  7960 7960  3540 S     0.0  1.5   0:04 httpd
26302 wwwrun    19   0  7860 7860  3548 S     0.0  1.5   0:03 httpd
26457 wwwrun    20   0  7828 7828  3552 S     0.0  1.5   0:03 httpd
26068 root      20   0  2828 2828  2500 S     0.0  0.5   0:00 httpd

result of free
             total       used       free     shared    buffers     cached
Mem:        513500     507896       5604          0     181692     176276
-/+ buffers/cache:     149928     363572
Swap:      1052248        332    1051916

Next follows tomorrow morning (German Time)

rgds.

Albert
 [2002-09-04 21:36 UTC] kalowsky@php.net 
You don't really need to report back any more memory, I believe you.  Honest!  Any chance you can try building with --enable-debug option and seeing if there are any told memory leaks?
 [2002-09-05 13:12 UTC] a dot steckenborn at stebosoft dot de 
is configured with --enable-debug

in php.ini
error_reporting  = E_ALL & ~E_NOTICE
report_memleaks = On

in the "ERROR Log" no Error Messages are shown.

I'm getting grazy with this
 [2002-09-08 12:30 UTC] kalowsky@php.net 
What ODBC driver are you using?  unixODBC, iODBC, ... ?
 [2002-09-08 14:47 UTC] a dot steckenborn at stebosoft dot de 
Hi,
i'm using the Adabas D ODBC Driver.
odbc.ini:
DRIVER=/usr/local/adabas/lib/odbclib.so
 [2002-10-01 07:31 UTC] rudi at kangaroo dot at 
i've got the same problem :( 
 
apache 1.3.26, php v4.2.3, adabas kernel 11.00.07  
odbc library odbclib.a (filesize 629128bytes, from adabas 
v10. the new one from v11 fails if reading long data).  
compiled php with the following options:  
 
'./configure' '--with-apxs=/usr/local/apache/bin/apxs' 
'--with-adabas=/database/adabas/' '--without-odbc' 
'--with-gd=/usr' '--with-jpeg-dir=/usr/lib' 
'--with-png-dir=/usr/lib' '--with-ttf' '--enable-ftp' 
'--enable-magic-quotes' '--enable-trackvars' 
'--with-zlib-dir=/usr'
 [2002-10-07 03:48 UTC] a dot steckenborn at stebosoft dot de 
hi,
i'm changing now from ADABAS D to SAPDB.
Meanwhile i'm thinking that this bug is a bug in the ADABAS ODBC Driver and not PHP related.
I need one week more for the migration and then wee will see if it's ADABAS D or PHP related.

The reason to migrate to SAPDB is that we can use the most of our sripts anymore and the support (for a free software)is much better.
Some of the scripts that are running on ADABAS D with errors so that we have to create db-Procedures, are running
on SAPDB without any errors.

That's the reason that i'm shure we can close our bug with the migration.

A lot of thanks to Kalowsky and everybody else for the help.

I will post the result of the migration around the 20021020.

With best regards

Albert Steckenborn
 [2002-10-26 10:07 UTC] a dot steckenborn at stebosoft dot de 
Hi again,

now we have converted to
SAPDB 7.3.00.25 (working better)
PHP 4.2.3
Apache 1.3.27


But one Error holds on.

If i'm requesting the database the first time no Error occurs but when i'm closing the result window and start a
new request within around 10seconds the following PHP Warning shows up in the Error log

-----snip---------
[26-Oct-2002 11:28:03] PHP Warning: SQL error: [SAP AG][LIBSQLOD SO][SAP
DB]Syntax error or access violation;
-3014 POS(260) Invalid end of SQL statement., SQL state 37000 in
SQLExecDirect in /www/kunden/reisenetz/web/show.phtml on line 153
-------snip-------------

The results of the second request are ok.

When i'm using ODBC_prepare following Warning comes up:
odbc_execute() supplied argument is not a valid ODBC result resource

The results are ok too.

It looks as if the ODBC_Close($conn) dont't work

It is the same Error as in ADABAS D 11

Hope that this will help.

With best regards

Albert Steckenborn
 [2002-10-26 16:25 UTC] sniper@php.net 
Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip
 [2002-10-27 04:08 UTC] a dot steckenborn at stebosoft dot de 
Nothing has changed with the latest snapshot
php4-200210270000

with a second ODBC-connect to the SAPDB database
within 10 sec. the PHP-error occours like before
--------snip-----
[27-Oct-2002 11:06:55] PHP Warning: SQL error: [SAP AG][LIBSQLOD SO][SAP DB]Syntax error or access violation;-3014 POS(272) Invalid end of SQL statement., SQL state 37000 in SQLPrepare in /www/kunden/reisenetz/web/show.phtml on line 151 [27-Oct-2002 11:06:55] PHP Warning: odbc_execute(): supplied argument is not a valid ODBC result resource in /www/kunden/reisenetz/web/show.phtml on line 152 [27-Oct-2002 11:07:05] PHP Warning: SQL error: [SAP AG][LIBSQLOD SO][SAP DB]Syntax error or access violation;-3014 POS(272) Invalid end of SQL statement., SQL state 37000 in SQLPrepare in /www/kunden/reisenetz/web/show.phtml on line 151 [27-Oct-2002 11:07:05] PHP Warning: odbc_execute(): supplied argument is not a valid ODBC result resource in /www/kunden/reisenetz/web/show.phtml on line 152 
--------snip-------------

but the ODBC_Result is ok.

The Memory-Usage looks very better with SAPDB,
PHP4.2.3 and Apache1.3.27
It seems as if my Memory-Leak is fixed.
 
Thanks a lot to all that are working at these problems

with best regards

Albert Steckenborn
 [2002-10-27 10:18 UTC] sniper@php.net 
updated version and summary.
 [2002-10-27 15:18 UTC] a dot steckenborn at stebosoft dot de 
today i've tested the whole day.

after logging the sql statements i found out,
that sometimes 2 requests are coming up, the first without the needed parameters and the second with.

And that is related by a bug in our select script.

Now I'm really shamed. :-(

Next time you are near by Ludwigshafen, Germany send me a mail you will get some free drinks by me.

A lot of thanks for your great work.

with best regards

Albert Steckenborn
 [2002-10-27 17:34 UTC] sniper@php.net 
So I guess this is bogus bug report then..? :)
 [2002-10-27 19:43 UTC] kalowsky@php.net 
Not completely bogus as the close bug was fixed for 4.2.3, but this was looking like a driver specific bug of it.  Thankfully it was truely driver specific.

Jani at the Kongress you better have a few drinks from this guy for me!
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Wed Apr 24 22:01:30 2024 UTC