# FW: Help needed in benchmarking memory patch

- Thread: https://externals.io/message/24342
- Original archive: https://news-web.php.net/php.internals/24342
- Started by Michael Vergoz on 2006-07-11T18:33:17+00:00
- Messages: 2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #24342 — Michael Vergoz — 2006-07-11T18:33:17+00:00

URL: https://externals.io/message/24342#24342

Here is a small patch allowing to correct the small leak. This one will have 
to be merge with that of Michael - (its patch is correct and does not 
contain any leak (I were not clear in my last mail) - thus +1)

http://badcode.be/~descript/PHP/PHP_5_2-php-main.diff

Michael Vergoz

----- Original Message ----- 
From: "Michael Vergoz" <mv-php@binarysec.com>
To: "Andi Gutmans" <andi@zend.com>; "'Dmitry Stogov'" <dmitry@zend.com>; 
"'PHPdev'" <internals@lists.php.net>
Sent: Tuesday, July 11, 2006 8:29 PM
Subject: Re: [PHP-DEV] FW: Help needed in benchmarking memory patch


> Salut Andi & Dmitry,
>
> If you have errors in your script you have a leak in 
> PG(last_error_message) & PG(last_error_file) because of php_error_cb() 
> which allocates via strdup() these two variables. It should be noted also 
> that these variables are not given with `NULL` after their freed in 
> php_error_cb() - main/main.c +679 and that both last allowance will never 
> be freed for each thread.
> They are freed with the stop of the process via php_module_shutdown().
>
> I propose to free these buffer in php_request_shutdown()? In fact the leak 
> more are the small ones but they become repetitive in a Threaded program.
>
> There is also another condition to generate large mem leak for example by 
> re-using a thread to carry out several script with the continuation. There 
> you explodes all the records if you do not do a ts_free_thread() just 
> after your php_request_shutdown(). It's for that which I think that it 
> would be very judicious to add a ts_free_thread() before each the return() 
> of the HttpExtensionProc() function of the ISAPI SAPI module.
>
> Michael Vergoz
>
> ----- Original Message ----- 
> From: "Andi Gutmans" <andi@zend.com>
> To: "'Michael Vergoz'" <mv-php@binarysec.com>; "'Dmitry Stogov'" 
> <dmitry@zend.com>; "'PHPdev'" <internals@lists.php.net>
> Sent: Tuesday, July 11, 2006 7:38 PM
> Subject: RE: [PHP-DEV] FW: Help needed in benchmarking memory patch
>
>
> > […]

---

## #24349 — Dmitry Stogov — 2006-07-12T06:51:55+00:00

URL: https://externals.io/message/24342#24349 · In reply to: #24342

Probably this patch is proper.
I'll test it today-tomorrow.

Thanks. Dmitry.

> -----Original Message-----
> From: Michael Vergoz [mailto:mv-php@binarysec.com] 
> Sent: Tuesday, July 11, 2006 10:33 PM
> To: Andi Gutmans; 'Dmitry Stogov'; 'PHPdev'
> Subject: Re: [PHP-DEV] FW: Help needed in benchmarking memory patch
> 
> 
> Here is a small patch allowing to correct the small leak. 
> This one will have 
> to be merge with that of Michael - (its patch is correct and does not 
> contain any leak (I were not clear in my last mail) - thus +1)
> 
> http://badcode.be/~descript/PHP/PHP_5_2-php-main.diff
> 
> Michael Vergoz
> 
> ----- Original Message ----- 
> From: "Michael Vergoz" <mv-php@binarysec.com>
> To: "Andi Gutmans" <andi@zend.com>; "'Dmitry Stogov'" 
> <dmitry@zend.com>; 
> "'PHPdev'" <internals@lists.php.net>
> Sent: Tuesday, July 11, 2006 8:29 PM
> Subject: Re: [PHP-DEV] FW: Help needed in benchmarking memory patch
> 
> 
> > […]
> php_error_cb() 
> > […]
> be noted also 
> > […]
> allowance will never 
> > […]
> php_module_shutdown().
> > […]
> In fact the 
> > […]
> Threaded program.
> > […]
> for example 
> > […]
> continuation. There 
> > […]
> ts_free_thread() just 
> > […]
> think that it 
> > […]
> each the return() 
> > […]
> running? One
> > […]
> memory patch
> > […]
> ISAPI should 
> > […]
> memory patch
> > […]
> Linux because 
> > […]
> separation is 
> > […]
> sapi_shutdown() and
> > […]
> that I find a 
> > […]
> memory patch
> > […]
> level. I 
> > […]
> user-memory can be 
> > […]
> environments 
> > […]
> attachment. You can 
> > […]
> it to scale 
> > […]
> seems to 
> > […]
> concurrencies we saw 
> > […]
> environment 
> > […]