Topic: Memory leak of gd.so (5.5.7)

Hi all,
maybe it's something with my configuration, but I didn't manage to fix it, so I'll post a possible bug with php-gd 5.5.7. Using htop VIRT column for memory footprint:
Without it, php-fpm has a 40-50 MB RAM usage per child.
With it, it raises to 550 MB right after starting (websites don't go down, in fact, just reading htop. free and top data).
With 5.4.23, which I was forced to use now, php-fpm has approx. 70 MB RAM usage per child.
All of the conf&ini files are stock and the same for all tests, CentOS Linux 6.5 32-bit, VPS OpenVZ with 512-1500 MB RAM, pm dynamic, 5 children at startup, 5 start, min and max spare servers, nginx/1.4.4. php.ini is at default state, except raising mem limit to 256 MB and post/upload size to 8 MB. MYSQL Version is 5.5.35-log, all php was installed via yum update, nothing compiled manually. More info at request.

Bug#2 - apcu 4.0.2 not showing System Cache Entries, Per-Directory Entries or User Cache Entries, only some aggregated numbers. Also it says it was running for 43 years (starting 1-1-1970, which also is not OK, I think). APC 3.1.15-dev works fine, as supposed. No changes were made to configuration file (apc.ini or apcu.ini in /etc/php.d).
Please, excuse me if something is not correctly described, English is not my primary language, and I'm not linux or php guru, just a lame user.
Thanks for your help!

Re: Memory leak of gd.so (5.5.7)

> Bug#2 - apcu 4.0.2 not showing System Cache Entries, Per-Directory Entries or User Cache Entries, only some aggregated numbers.

I don't know which report you are using.

APCU is only a user data cache, so  System Cache Entries, Per-Directory Entries have no sense and so information returned by apc_sma_info or apc_cache_info are a bit different.

Upcoming version 4.0.3 will solves some difference and will be closer to APC output.

APC 3.1.15-dev could work in some configuration (I know it is reported to crash a lot with FPM), but is not maintained anymore.

For opcode cache, see php-opcache, new official and maintained upstream project.

Laptop:  Fedora 38 + rpmfusion + remi (SCL only)
x86_64 builder: Fedora 39 + rpmfusion + remi-test
aarch64 builder: RHEL 9 with EPEL
Hosting Server: CentOS 8 Stream with EPEL, rpmfusion, remi

Re: Memory leak of gd.so (5.5.7)

I didn't realize the difference between apc and apcu and always monitored "what's going on" through apc.php (which, as pointed, didn't show much useful data when apcU is installed).
I'll give a try to php-opcache, thanks a lot.

Re: Memory leak of gd.so (5.5.7)

I confirm the huge memory consumption (~500MB) with php-gd, will try to investigate a little.

Laptop:  Fedora 38 + rpmfusion + remi (SCL only)
x86_64 builder: Fedora 39 + rpmfusion + remi-test
aarch64 builder: RHEL 9 with EPEL
Hosting Server: CentOS 8 Stream with EPEL, rpmfusion, remi

Re: Memory leak of gd.so (5.5.7)

After some investigation, issue comes from libvpx.
Using libgd without libvpx support solves this issue ("php -a" uses <20MB)
Using libgd with libvpx 0.9 or 1.2 raises it ("php -a" uses >500MB)

Will try so see if I can found some explanation, else will probably drop libvpx support.

Laptop:  Fedora 38 + rpmfusion + remi (SCL only)
x86_64 builder: Fedora 39 + rpmfusion + remi-test
aarch64 builder: RHEL 9 with EPEL
Hosting Server: CentOS 8 Stream with EPEL, rpmfusion, remi

Re: Memory leak of gd.so (5.5.7)

Thank you.
Maybe this is related, even it's old thread: http://code.google.com/p/webm/issues/detail?id=247, as they mention explicitly "32 bit builds run out of memory", such as mine. But, as I said, it's 2-3 years old problem and maybe wrong direction.

Re: Memory leak of gd.so (5.5.7)

Can you try to update gd-last to 2.1.0-2, without libvpx support, seems to fix this issue.

Laptop:  Fedora 38 + rpmfusion + remi (SCL only)
x86_64 builder: Fedora 39 + rpmfusion + remi-test
aarch64 builder: RHEL 9 with EPEL
Hosting Server: CentOS 8 Stream with EPEL, rpmfusion, remi

Re: Memory leak of gd.so (5.5.7)

DJPlamen wrote:

I didn't realize the difference between apc and apcu and always monitored "what's going on" through apc.php (which, as pointed, didn't show much useful data when apcU is installed).
I'll give a try to php-opcache, thanks a lot.

You need to use apcu-panel package which provides the updated monitor page.

For opcache, you can try something like https://github.com/rlerdorf/opcache-status (a single small php page)

Laptop:  Fedora 38 + rpmfusion + remi (SCL only)
x86_64 builder: Fedora 39 + rpmfusion + remi-test
aarch64 builder: RHEL 9 with EPEL
Hosting Server: CentOS 8 Stream with EPEL, rpmfusion, remi

9 (edited by DJPlamen 2013-12-29 18:06:23)

Re: Memory leak of gd.so (5.5.7)

First updated php, using remi55 repo, because I was with 5.4.23. Then I did

yum reinstall --enablerepo=remi-test gd-last

All went well, got your test version 2.
Then tried to start php-fpm and got:

Starting php-fpm: [29-Dec-2013 19:59:56] NOTICE: PHP message: PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib/php/modules/gd.so' - /usr/lib/php/modules/gd.so: undefined symbol: gdImageWebpCtx in Unknown on line 0

(started, but no gd loaded)

Re: Memory leak of gd.so (5.5.7)

Damn sad

New build running...
I should probably not be so reactive...

Laptop:  Fedora 38 + rpmfusion + remi (SCL only)
x86_64 builder: Fedora 39 + rpmfusion + remi-test
aarch64 builder: RHEL 9 with EPEL
Hosting Server: CentOS 8 Stream with EPEL, rpmfusion, remi

Re: Memory leak of gd.so (5.5.7)

I have remove gd-last-2.1.0-2 from the repo.
Will work on this issue later.

Laptop:  Fedora 38 + rpmfusion + remi (SCL only)
x86_64 builder: Fedora 39 + rpmfusion + remi-test
aarch64 builder: RHEL 9 with EPEL
Hosting Server: CentOS 8 Stream with EPEL, rpmfusion, remi

Re: Memory leak of gd.so (5.5.7)

Hi Remi,

weren't you able to disable libvpx in newer builds (e.g., in 5.5.8)?
Was forced to downgrade to 5.4 on some VPSes because of this bug, so looking forward for more info.

Thank you for your work!

Re: Memory leak of gd.so (5.5.7)

No, this is not related to libvpx (a build with libvpx disabled, or updated, doesn't solves this issue).

Laptop:  Fedora 38 + rpmfusion + remi (SCL only)
x86_64 builder: Fedora 39 + rpmfusion + remi-test
aarch64 builder: RHEL 9 with EPEL
Hosting Server: CentOS 8 Stream with EPEL, rpmfusion, remi

Re: Memory leak of gd.so (5.5.7)

Hey,

still having problem with memory leak with gd (php5.5.10)... Will there be any fix soon?

Re: Memory leak of gd.so (5.5.7)

> Will there be any fix soon?
Have you any patch to propose ?

Laptop:  Fedora 38 + rpmfusion + remi (SCL only)
x86_64 builder: Fedora 39 + rpmfusion + remi-test
aarch64 builder: RHEL 9 with EPEL
Hosting Server: CentOS 8 Stream with EPEL, rpmfusion, remi

Re: Memory leak of gd.so (5.5.7)

Once again, there is no memory leak, memory consumption is high but stable.

This issue only affects RHEL-6 build, not fedora nor RHEL-7 build, so the issue is in one of the system libraries used.
So it will be quite difficult to have this fixed, as this probably can't be fixed in the PHP side.

Laptop:  Fedora 38 + rpmfusion + remi (SCL only)
x86_64 builder: Fedora 39 + rpmfusion + remi-test
aarch64 builder: RHEL 9 with EPEL
Hosting Server: CentOS 8 Stream with EPEL, rpmfusion, remi

Re: Memory leak of gd.so (5.5.7)

Can you please test php-5.5.10-1.el6.remi.1.x86_64 + gd-last-2.1.0-2.el6.remi.x86_64 from remi-test repo.

yum --enablerepo=remi-test update --exclude php-pecl\* php\* gd\*

It seems this solves the memory consumption.

Feedback expected.


P.S. EL-6 x86_64 only, will wait for feedback before running other builds (other arch, EL-5, php 5.6, ...)

Laptop:  Fedora 38 + rpmfusion + remi (SCL only)
x86_64 builder: Fedora 39 + rpmfusion + remi-test
aarch64 builder: RHEL 9 with EPEL
Hosting Server: CentOS 8 Stream with EPEL, rpmfusion, remi

Re: Memory leak of gd.so (5.5.7)

Bug tracker for this libvpx issue : Bug #1075434

Laptop:  Fedora 38 + rpmfusion + remi (SCL only)
x86_64 builder: Fedora 39 + rpmfusion + remi-test
aarch64 builder: RHEL 9 with EPEL
Hosting Server: CentOS 8 Stream with EPEL, rpmfusion, remi

Re: Memory leak of gd.so (5.5.7)

Remi wrote:

Can you please test php-5.5.10-1.el6.remi.1.x86_64 + gd-last-2.1.0-2.el6.remi.x86_64 from remi-test repo.

yum --enablerepo=remi-test update --exclude php-pecl\* php\* gd\*

It seems this solves the memory consumption.

Feedback expected.


P.S. EL-6 x86_64 only, will wait for feedback before running other builds (other arch, EL-5, php 5.6, ...)

Just tested on CentOS release 6.5 (Final) x86_64 and can confirm that memory is now ok.

Re: Memory leak of gd.so (5.5.7)

@nejc, thanks for the feedback.

Laptop:  Fedora 38 + rpmfusion + remi (SCL only)
x86_64 builder: Fedora 39 + rpmfusion + remi-test
aarch64 builder: RHEL 9 with EPEL
Hosting Server: CentOS 8 Stream with EPEL, rpmfusion, remi

Re: Memory leak of gd.so (5.5.7)

As libvpx 1.3.0 is now part of rhel/centos 6/7 updates, I have reenable WebP support
(gd-2.1.0-3.el6.remi, php-gd-5.1.16-1.el6.remi.1, php-gd-5.6.0-1.el6.remi.1, php56-php-gd-5.6.0-1.el6.remi.1, soon in the repo).

No more memory leak detected.

Laptop:  Fedora 38 + rpmfusion + remi (SCL only)
x86_64 builder: Fedora 39 + rpmfusion + remi-test
aarch64 builder: RHEL 9 with EPEL
Hosting Server: CentOS 8 Stream with EPEL, rpmfusion, remi