Jump to content


Photo

httpd1.exe Security Token Handle Leak (MEMLEAK)


  • Please log in to reply
11 replies to this topic

#1 ShadowIllusion

ShadowIllusion

    Junior Member

  • Member
  • Pip
  • 12 posts
  • Main OS: Windows Vista

Posted 24 July 2012 - 08:14 AM

OS I have tried: Windows 7 SP1 and Windows Server 2008 R2 (both is 64-bit OS)...

Uniserver version I have tried: 8.5.8-Coral and 8.5.5-Coral

How to reproduce this problem:
1. Download Uniserver 8.5.5-Coral and extract it. Run apache and mysql as usual.

2. Download Process Explorer http://download.sysi...essExplorer.zip and extract it.

3. Run Process Explorer as Administrator, then View > Select Columns. In "Process Performance" tab, tick "Handle Count" > OK. After this, click View > Lower Pane View > tick "Handle"...

4. Click on httpd1.exe child processes which have around 300 handle count at startup... The lower pane will show the handle list...

5. Open your favorite browser, and go to http://127.0.0.1

Everytime you press refresh (F5) on your browser (re-request the webserver), you will notice that httpd1.exe have 1 more handle count in Process Explorer window... In the lower pane view, you will notice that 1 new security token handle is created with the name format like this: YOURCOMPUTERNAME\YOURUSERNAME:RANDOMTOKEN

This is where the problem happened. Everytime httpd1.exe server new web request, the handle is created, but NEVER closed, and will hogging system resources over time. It's okay on test server, but once you put it in production server with real websites running, the opened Handle Count of httpd1.exe will increase to a very high number...

In my server, it goes from 300 (at startup) to 1 million opened handle only in 2 days! Other process only consumes around 10 ~ 2000 handles. httpd1.exe memory consumption still remains around 20mb, but because handle consumes kernel space, your ram usage will increase around +512mb mysteriously for every 1 million handle...

In only two weeks, my server experience some slowdowns / freeze because too much handle for Windows to hold... I need to restart Uniserver Apache service every few days so the handle count reset back to around 300 after restart (and it will goes up quickly again everytime the world accessing my websites)...

If you want to mimic the behaviour of production server, after accessing http://127.0.0.1 try to hold down F5 buttons for 1 minutes... See how is the handle count now...

It only happened since I upgrade to 8.5.5-Coral (I'm sorry I forget the version before this which doesn't have this leak issues)... Maybe it's the problem on Apache or PHP compilation...

Attached File  ss.jpg   170.7KB   31 downloads

#2 John Smith

John Smith

    Junior Member

  • Member
  • Pip
  • 10 posts
  • Main OS: Windows 7

Posted 24 July 2012 - 09:28 AM

To add something to the empirical data:

I just tried 8.5.7-Coral on Windows Server 2008 32-Bit and the problem did not occur for me. After torturing the F5 button for a minute, I could see the handle count went up about 100 and then stayed there no matter how often I refreshed.

#3 ShadowIllusion

ShadowIllusion

    Junior Member

  • Member
  • Pip
  • 12 posts
  • Main OS: Windows Vista

Posted 25 July 2012 - 03:48 AM

Thanks for the info. Have you tried on 64-bit systems?

#4 Crypton

Crypton

    Junior Member

  • Member
  • Pip
  • 10 posts
  • Location:Czech Republic
  • Main OS: Windows 7

Posted 25 July 2012 - 06:38 AM

I confirm this issue on Windows 7 SP1 x64. Not only tokens, but also threads! There are about ~200 threads created! Most of them are in suspended state. This must be also leak, no application need so many threads as 8 threads is enough for ordinary thread pool. One thread takes 2MB of RAM (for the stack), so it's like ~400MB leak! Or not?

Have to restart my server periodically...

#5 ShadowIllusion

ShadowIllusion

    Junior Member

  • Member
  • Pip
  • 12 posts
  • Main OS: Windows Vista

Posted 25 July 2012 - 04:28 PM

I wonder why if I refresh the default uniserver index.php, it leaks handle, while if change it with static index.html, it doesn't leak...

So I try open default uniserver index.php, commenting some function, then test refresh again...

Turns out that is_readable() function in line 7 of index.php was the culprit...

Try this simple script, save as index.php


<?php
if (is_readable("index.php"))
?>

^
it will leak handles each time this is executed. but if you change value index.php to something else (so file doesnt exist and is_readable() return false), it will not leak handles...

this is php bugs...

#6 ShadowIllusion

ShadowIllusion

    Junior Member

  • Member
  • Pip
  • 12 posts
  • Main OS: Windows Vista

Posted 25 July 2012 - 05:22 PM

After browsing through php sites, seems there's already a bug report:

https://bugs.php.net/bug.php?id=62444

It seems happened since introduction of php 5.3.0. If you see in the changelogs:

http://www.php.net/ChangeLog-5.php

Added support for ACL (is_writable, is_readable, reports now correct results) on Windows. (Pierre, Venkat Raman Don, Kanwaljeet Singla)


Temporary solution:

Revert back to UniServer 5.6a-Nano http://forum.uniform...?showtopic=1878 because it uses PHP 5.2.13. But the old apache version somehow turns me off because eaccelerator often crashes the apache. New apache seems more stable and consumes less memory.

#7 John Smith

John Smith

    Junior Member

  • Member
  • Pip
  • 10 posts
  • Main OS: Windows 7

Posted 26 July 2012 - 09:15 AM

One wonders why this bug has not been fixed yet, since it's such a crucial thing and we are at PHP 5.4.5 already... :)

#8 ShadowIllusion

ShadowIllusion

    Junior Member

  • Member
  • Pip
  • 12 posts
  • Main OS: Windows Vista

Posted 26 July 2012 - 11:39 AM

Because most people use linux on production server, and windows for testing?

#9 Ric

Ric

    Project Manager

  • Admin
  • PipPipPipPipPip
  • 1,421 posts
  • Gender:Male
  • Location:Cambridge,UK
  • Interests:Electronics
    Internet in general
    Open source projects
  • SourceForge IDmpgcan
  • Wiki ID: Ric
  • Main OS: Windows XP

Posted 26 July 2012 - 02:17 PM

A bug not reported is never going to be fixed then again a reported bug may be ignored. That said perhaps the following two submitted bug reports will be addressed in the next releases of PHP:

https://bugs.php.net/bug.php?id=62444
https://bugs.php.net/bug.php?id=62669

All the best
Ric :)

#10 ShadowIllusion

ShadowIllusion

    Junior Member

  • Member
  • Pip
  • 12 posts
  • Main OS: Windows Vista

Posted 20 August 2012 - 12:05 PM

Can you include PHP 5.4.6/PHP 5.2.13 instead of PHP 5.4.6/PHP 5.3.16 in the 9 beta. That's because 5.2.13 didn't have this bugs, and very suitable for production server.

#11 Ric

Ric

    Project Manager

  • Admin
  • PipPipPipPipPip
  • 1,421 posts
  • Gender:Male
  • Location:Cambridge,UK
  • Interests:Electronics
    Internet in general
    Open source projects
  • SourceForge IDmpgcan
  • Wiki ID: Ric
  • Main OS: Windows XP

Posted 22 November 2012 - 07:48 AM

Please note the above bug (https://bugs.php.net/bug.php?id=62444)
has been resolved. Fixed in PHP releases 5.4.9 and 5.3.19

Coral 8.6.8 - Updated PHP to 5.4.9

All the best
Ric :)

#12 BobS

BobS

    Project Helper

  • Super Moderator
  • PipPipPip
  • 333 posts
  • Location:Santiago Chile
  • Interests:Retiring, computer systems, system design, model railroads....
  • Wiki ID: BobS
  • Main OS: Windows 7

Posted 22 November 2012 - 10:32 AM

It looks like these new versions need to be put into the next release of Steel-9 Beta. But I suppose you realize this... ;)

Regards,
BobS




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users